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1. MOBITEX OVERVIEW 

The Cantel Mobitex system is a trunked land based communications system 
designed to cany data traffic between fixed and mobile terminals. The Mobitex 
System consists of a Network and a collection of subscribers. The Network is 
a common carrier which transports information packages (packets). The 
subscribers are customers who have contracted with Cantel the Mobitex 
network operator, to use the network services. Each subscriber must own, 
lease, or otherwise have access to a terminal through which he or she can 
transmit and receive messages. The contract between the subscriber and 
Cantel is referred to as a subscription. 

This specification is intended to provide a description of the Mobitex system in 
Canada sufficient to permit understanding of the system operation and terminal 
requirements, so that engineers, software designers, and manufacturers can 
design, manufacture, and test equipment which may be developed and sold as 
subscriber terminals in the Cantel Mobitex system. 

While this specification has been developed for the design and manufacture of. 
terminals for use in Canada, it also provides limited comments' on the 
differences between Canadian and the US Mobitex systems, for the benefit of 
any manufacturers who wish to develop Mobitex terminals which are compatible 
for use throughout North America. 

The applications of Mobitex to commerce are limited only by the creativity of the 
subscribers. The more common expected uses are: 

1. Dispatch traffic, consisting of brief messages from a dispatcher in an office 
to mobile units in the field. 

2. Requests for information or instructions from field operators to superiors and 
replies to such requests. 

3. Data base access, where there is need to obtain information from a computer. 

4. Data transfer, as between a computer in a vehicle and a computer in an office 
or data processing center. 

5. Resource monitoring, such as keeping track of field staff and the completion 
of field tasks to aid in the efficient further dispatching or recall of personnel 
and equipment. 

6. Resource control, such as the remote controlling of power plants, heating 
and air conditioning systems, processing facilities, etc., in remote or rural 
areas where wireline facilities are unavailable and expensive to install. 

7. Fixed or mobile remote data gathering devices. 
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As seen from this list, communications may be between people, between a 
person and a machine (including but not limited to computers), and between 
computers (including between a computer controlled machine and its 
controHec).7ne electromagnetic spectrum through which radio communication is 
feasible is limited, and it is important that users of the spectrum use it efficiently. 
Data communication is inherently much more efficient in spectrum use than 
voice communication. It allows many more users to share a single radio 
channel for information transfer than does voice transmission. Cellular 
communication, in which a low power channel may be reused several, times 
within a metropolitan area, is also more efficient in spectrum use than the higher 
power broadcast communications, in which a channel can only be used once 
in a metropolitan area, and requires large separation distances before channels 
can be reused. The Mobitex system combines the advantages and efficiencies 
of data communication and cellular networking to provide a highly efficient use 
of the radio spectrum for message communicatiba 

The Mobitex system is complex, and this specification provides a requirements 
description to the extent necessary for equipment designers, manufacturers, and 
Mobitex customers to understand it and to permit development, manufacture, 
and proper use of MobitBx terminal equipment. Chapter 2 provides a brief 
system description of the Mobitex system. The subsequent chapters provide the 
details necessary for terminal equipment design. 
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INTRODUCTION TO ISSUE NO. 1 



This is Cantel"s first issue of the 8K Mobitex Terminal Spedfication. It applies 
to fixed, mobile and portable terminals to be used with the Mobitex Network, 
which is installed and operated by Rogers Cantel Mobile Inc. in Canada 

The major part of this document was prepared by ERITEL AB, a Swedish 
Company, under the auspices of the Mobitex Operators Association (MO A), 
which is a group of representatives from all countries that use the basic Mobitex 
System. It should be noted that equipment built to this specification will also 
operate on the Mobitex Network operated by RAM Mobile Data in the United 
States. This document also includes requirements for equipment that will 
operate with other networks. 

For example, some networks are permitted to offer optional voice service over 
their Mobitex network, whereas in Canada and the United States, voice service 
is not offered. Therefore^ reguirements herein that apply to voice service are not 
applicable to terminals that will be sold for use on the Cantel Mobitex network. 
The voice requirements have been left in the spcification so a manufacturer can 
consider designing a common product for sale in Canada, or elsewhere. 

This document is divided into chapters. Chapter 1 is an introduction to the 
specification. Chapter 2 is an overview of the Mobitex system. Chapter 3 
includes a general discussion of terminals. Chapter 4 includes a glossary of 
terminology and acronyms. Chapter 5 includes a fist of references. The 
following chapters include the design requirements for each subunit of the 
terminal produces): 

1. For a fixed terminal 

Chapter 8 - Application Layer 
Chapter 9 - Network Layer 
Chapter 11 - Link Layer and Physical Layer 
Chapter 12 - Other Requirements 

2. For the mobile radio 

Chapter 18 - Radio Equipment 
Chapter 20 - Other Requirements 

3. For the mobile and portable modem/radio controller 

Chapter 9 - (Appendix C) - Network Layer 
Chapter 15 - Draft Hand-held Portable Protocol 
Chapter 16 - Link Layer 
Chapter 17 - Physical Layer 
Chapter 19 - Other Interfaces 
Chapter 20 - Other Requirements 
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Chapter 6 includes all requirements not re 
to the use of terminals in Canada 


corded elsewhere that are applicable 




A manufacturer has the option of designing and supplying fixed terminals and/or 
mobile terminals. The latter can be broken down into the radio, 
modern/controller, and user terminal. Therefore, a manufacturer can elect to 
provide a total assembly of all three parts, a radio, a modem/controller, or a 
terminal, or any applicable combination of the above. 




To facilitate interconnection of mobile 
manufacturers, and to permit standard 
electro/mechanical Interfaces are defined 


terminal components from various 
ization of vehicle cabling, specific 
herein for each component 




If a manufacturer elects to design a combined radio modem in one housing, the 
interface specified herein would not apply. Unwise, if a manufacturer elects to 
manufacture a totally integrated radio/modem terminal, such as a hand held 
unit, the interfaces herein need not apply. 




- - ^Al. questions or comments related to this Cantel - version of the Mobitex - _ 

specification should be sent to Cantel. The address is: 




Terminal Specifications Inquiries 
Rogers Cantel Mobile Inc. 
Data Communications Division 
40 Eglinton Ave. East 
Toronto, Ontario 
Canada 
M4P 3A2 






Phone: (416) 440 1400 
Fax: (416) 480 9069 






Numbered copies of this specification will.be issued on request to the above. 
Revision material will be periodically issued and sent to" each registered holder 
of the specification. 




Transfer of a numbered specification within a company should be reported to 
Cantel at the above address so revision material will be sent to the proper 
person. Copies made of this specification must be internally controlled since 
revision material will only be sent to registered holders of the specification. 
Copes may not be distributed outside the organization to which the 
specification was originally issued. 
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SIGNIFICANT CHANGES FROM SPECIFICATIONS R4B: 

1. Transferable subscriptions" have been renamed "Personal subscriptions" 
(Sect 3.1.2). 

2. Emergency traffic is not restricted to origination from mobile terminals 
(Sect 3.2.3). 

3. A "network identification" has been added to accommodate joint traffic where 
multiple networks exist (Sea 3.3.12). 

4. A •traffic area identification* has been added to specify geographical areas 
for mobile control (Sect. 3.3.13). 

5. The time limit before transmit of an "active" message after loss of network 
contact In Sect. 7.1.2 has been changed and is specified in R1-06. 

6. An electronic serial number is now required on all mobile terminals (Sect 
8.£6). 

7. References to a "National System Channel" have been replaced by "System 
Channel" to reflect the fact that system channels may vary by geographical 
area (Sect. 9.1.2). 

8. All references to VOICE services may be ignored. 

9. An appendix has been added to this section. It contains on overview of 
the new roaming algorithm to be used in the 8000 bps Mobltex system. 

10. Section 15, Protocol for hand-held terminals has been added. 
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SOMMARY 

This document is an introduction to HOBITEX TERMINAL 
SPECIFICATION. The document explains the purpose of the 
specifications included, as well as how they are arranged. 
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This set of documents contains specifications and 
recommendations for fixed and mobile terminals to be 
connected to the MOBITEX network. 

The purpose of the contents, is to define how a terminal 
is to function to be used in the MOBITEX network. 

Terminals that should be connected to MOBITEX are tested 
in accordance with these specifications. 

To every MOBITEX system, one or several unique binders of 
MOBITEX TERMINAL SPECIFICATION [MTS) is made up. The 
reader should observe, for which network and terminal type 
the specification is relevant. 
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2 DOCUMENT ARRANGEMENTS 



2.1 SECTION ORGANIZATION 



The documents are divided into three main parts as shown 
below. 



Common sections 

Common documents both for fixed and mobile terminals, such 
as system descriptions, .network operator information and 
protocols for higher layers. 



Fixed terminal sections 



Mobile terminal sections 

Documents refering to mobile terminals, such as protocols 
and specifications for radio equipment. 

The following chapters show the contents and the purpose 
of each section. 
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2.2 COMMON DOCUMENTS 

Section Arrangement of the documents 

Includes this document, and a document list which shows 
the document number and revision of all documents 
included in the present specification. 



Section System description MOBITEX 

The MOBITEX communication network is described in 
general. It is shown where the terminals are connected 
to the network, how the network is designed and where 
the interface between the network and the terminal is. 

This section also describes the subscription types and 
services in the network. 



Section General description of terminals 

Provides a general description of the MOBITEX 
terminals, i.e. fixed and mobile terminals. 



Section Terminology 

Describes terms and abbreviations used in the 
specifications. 



Section References 



Gives a general illustration of the national and 
international documents .referred to in this 
specification. 



Section Network operator " information 

Consists of any type of network operator information. 
It could be related to both the network, such as. bit 
rates for fixed terminals, frequency plans and network 
operator addresses etc. 

This section completes the specification with 
information not given in the other sections. It is 
therefore important that the reader is familiar with 
the contents of this section. 
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Section Application layer 

Specifies the interface to the user of the terminals, 
i.e. how the terminal should support the subscriber 
when using the terminal. 

The application layer interface to the lower layers is 
also specified. 



Section Network layer 

Specifies the structure of packets' used by both the 
HOB I TEX network and the terminals. It is also specified 
how packets are transmitted between the sender and the 
addressee. 

As a guide-line for implementation, a logical descrip- 
tion of the network layer for mobile terminals is also 
included. 
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2.3 DOCUMENTS RELATED TO FIXED TERMINALS 



Section Interface requirements, fixed terminal 

Specifies the different types of line interface's for 
the link layer and physical layer, with connection 
procedure and frame si2es. The documents refers to a 
considerable degree to ISO standards. 

Section Other interfaces, fixed terminal 

See section "Other interfaces, mobile and fixed 
terminal". 



Section Other requirements, fixed terminal 

Contains requirements for the environment, power 
supply, marking control devices and indications. 
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2.4 DOCUMENTS RELATED TO MOBILE TERMINALS 



Section Link layer, mobile terminal 



Specifies the radio interface's link layer with coding, 
frame structure, transmission of frames etc. 

As a guide line for implementation, it also consists of 
a logical description. 

Section Physical layer, mobile terminal 

Specifies carrier wave modulation and conversion 
between digital data and analog signals. 

As a guide line for implementation, it also consists of 
a logical description. 



Section Radio equipment, mobile terminal 

Contains requirements for the mobile terminal's radio 
equipment. 

Section Other interfaces mobile and terminal 

Provides recommendations of which protocol to be used 
for the interfaces between the mobile terminal's 
central unit and peripheral equipment such as printers, 
external operator units etc. 

This recommendation is also used to show which protocol 
to be used for the interfaces between the mobile 
terminal's central unit and fixed terminals. 



Section General requirements , mobile terminal 

Contains requirements for the environment, power 
supply, marking, control devices and indicators. 
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3 DOCUMENT ADMINISTRATION 



This chapter will give the reader a brief idea of how to 
identify the included documents and how to use the 
internal references. 



3.1 DOCUMENT IDENTIFICATION 

Each individual document in the terminal specification has 
its own unique document number. This number is written at 
the top of each page to the right, in' the field "No". This 
document, for example, has document number: 

1551-LZBA 703 1001 Ue. 

Below the document number is the printing date of the 
document, on the form year-month-day, and the current 
revision of the document. 

Each document also got its own designation to be used in 
daily speech. This designation refers to the library 
section, and its version related to" frequency, baud- rate, 
function etc. The designation is placed under document 
identification number in the field "File". 

The following format is used: 

MTSNNA.X 

MTS begins all designations 

(= Mobitex Terminal Specification) 

NN section number used in the binder, 1-20 

A appendix, A-Z (used when applicable)) 

X version, 1 - n (related to frequency, baud 

rate, function etc.) 

This document, for example, has document designation: 

MTS01.1 

On the next page, is the first version of each document 
listed. (Due to extended functionality new versions may 
have been made up.) 
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Designation 

MTS0Q.1 

MTS01.1 

MTS02.1 

MTS03.1 

MTS04.1 

MTS05.1 

MTS06.1 

MTS08.1 

MTS09.1 
MTS09A.1 
MTS09B.1 
MTS09C.1 

MTS11HDLC.1 
MTS11X25.1 
MTSUBSC.l 
MTSUMASC.l 
MTS11MPAD.1 

MTS12.1 

MTS16 . 1 
MTS16A.1 



MTS18.1 
MTS18A. 1 

MTS19_1 
MTS19A.1 
MTS19B.1 
MTS19C.1 



Document title / Binder section title 
Caption list 

Arrangement of the documents 
Document list 

MOB I TEX System description 
General description of terminals 
Terminology 
References 

Network operator documents 
Application layer 

Network layer 

- " -, Packet formats 

- " Dialogues 

- " -, Logical description (8 kbps only) 

Interface requirements, fixed term. - HDLC 

- " - X.25 

- " -, - BSC 

- " - MASC 

- " -, - MP AD 

Other requirements, fixed terminal 

Link layer, mobile terminal 

Link layer, mobile, terminal - Frames 

Physical layer, mobile terminal 

Mobile radio equipment 

- " Measurement methods 

Other interfaces, mobile and fixed term. 

- " -, Commands 

- " -, Application example 

- " Monitoring other channels than 

MOBITEX (1200 bps only) 

Other requirements, mobile terminal 
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On the last page of each document an index which shows. all 
references made in the document and on which page(s) they 
are made. 

The references are made on the form Rl-nn, where nn refers 
to the section. 



The reference designations used is also shown on the last 
page of the document. 



3.3 SPECIFICATION SEPARATION 

The terminal specification can be separated into two 
specifications, one for the mobile terminals and another 
for the fixed .terminals. The common sections (l->9-) are the 
same in both the specifications. 

Below are the identification numbers of the binders when 
separated: 

MOBITEX fixed terminal specification 01/LZBA 703 1'001/nn 

MOBITEX mobile terminal specification 02/LZBA 703 1001/nn 

The suffix added after the identification number shows 
which network operator the specifications are intended 
for. 
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MOBITEX SYSTEM DESCRIPTION 



ABSTRACT 

This document gives a brief description of MOBITEX, a 
trunked land-based communication system, which is 
primarily designed for data and speech traffic between • 
fixed and mobile terminals. 

"This description does not apply to any particular release 
of the system, and contains no requirements for 
implementation of terminal functions. 



Exhibit 2, p. 33 



3jc 3=„; 

2 


Cantel Mobitex- 


Sr-N, 1 | 

1551 - A 295 5073 Ue 


1990-02-19 J 1 MTS02.1 



TABLE OF CONTENTS 



1 INTRODUCTION 4 

2 BASIC REQUIREMENTS 5 

3 TRAFFIC FACILITIES 6 

3.1 SUBSCRIPTION ' 6 

3.1.1 Terminal subscription 6 

3.1.2 Personal subscription 6 

3.2- SUBSCRIPTION SERVICES 7 

3.2.1 Message traffic 7 

3.2.2 Speech (line-connected traffic) 8 

3.2.3 Emergency traffic 9 

3.2.4 Group traffic 11 

-3,3- - - SUBSCRIPTION FUNCTIONS 13 

3.3.1 Text/data-traffic 13 

3.3.2 Status traffic 13 

3.3.3 Speech traffic/line connection ....14 

3.3.4 Password .14 

3.3.5 Emergency traffic • 14 

3.3.6 Group traffic for messages 14 

3.3.7 Group traffic speech {line connection) ; 14 

3.3.8 Closed user groups 14 

3.3.9 Partially active in MOB I TEX 15 

3.3.10 Data interruption in a line connection 15 

3.3.11 Mailbox IS 

3". 3. 12 Joint-traffic 15 

3.3.13 Traffic areas IS 

3.3.14 External networks 17 

3.4 TRAFFIC LIMITATIONS 18 

3.4.1 Text/data traffic 18 

3.4.2 Line connection 18 

4 CHARGING PRINCIPLES '. 19 

5 NUMBERING 20 

6 NETWORK STRUCTURE , 21 

6.1 NETWORK HIERARCHY 21 

6.2 MAIN COMPONENTS OF THE NETWORK .22 

6.2.1 Base radio stations (BAS) 22 

6.2.2 Area exchanges (MOX) 22 

6.2.3 Main exchanges (MHX) 22 

6.2-4 Network control centre (NCC) 22 

6.2.5 Connections ■ 23 

7 TRAFFIC ROUTING 24 

7.1 SUBSCRIPTION INFORMATION 24 



Exhibit 2, p. 34 



_ .... ... 15S1 - ft 296 5073 He 

CantelMobitex- ps 



7.1.1 Static subscription information 24 

7.1.2 Dynamic subscription information 24 

7.2 ERROR HANDLING 26 

7.3 RESERVE ROUTES 26 

7.4 AUTONOMOUS OPERATION 25 

7.5 TRAFFIC CONTROL AND OPTIMIZATION 27 

8 TERMINALS 28 

8 . 1 FIXED TERMINALS .28 

8.1.1 General 28 

8.1.2 Packet oriented terminals . 28 

8.1.3 Character oriented terminals 29 

8.2 MOBILE TERMINALS 29 

8.2.1 General 29 

8.2.2 Radio unit .. 29 

8.2.3 Control unit 30 

8.2.4 Operator unit 30 

8.2.5 Peripheral equipment 31 

8.2.6 Serial number control 31 

9 RADIO PATH ...32 

9.1 RADIO FREQUENCIES ' 32 

9.1.1 Frequency bands and channel numbering ....... ..32 

9.1.2 Channel usage ° ...32 

9.2 TRAFFIC CAPACITY 33 

9.3 RADIO PROTOCOL : 34 

9.3.1 GENERAL * 34 

9.3.2 RADIO DATA TRANSMISSION SPEED 34 

9.3.3 FRAME STRUCTURE 34 

9.3.4 BASIC RULES 35 

9.3.5 ADDRESSING AND CHOICE OF BASE RADIO STATION ...35 

9.3.6 REPETITION 35 

'9.3.7 MESSAGE SEQUENCE NUMBERS 36 

9.3.8 CHANNEL ACCESS ALGORITHMS 36 

9.3.9 MOBILE FLEET DIVISION 37 

9.3.10 SYSTEM SIGNALLING 37 

9.4 TRAFFIC HANDLING ON RADIO CHANNELS 38 



Exhibit 2, p. 35 



Cantel Mobitex- 



1 INTRODUCTION 

The major part of today's land mobile communication is of 
the dispatch type, .i.e. communication between field 
personnel in mobile units and their dispatch centres. 
Most communication is in the form of speech. Each company 
normally has its own radio system and has been assigned a 
frequency channel to be shared with other companies in the 
same area, or has been assigned its own frequency channels 
with little or small potential for inter-company traffic 
should this be required. In most cases the frequencies are 
used very inefficiently. 

The increasing demand for land mobile communication and 
the limited availability of frequencies has resulted in an 
acute deficiency of frequencies in several geographical 
areas, particularly in and around major urban areas. The 
only solution to this problem is to use the frequencies 
more efficiently. One way of doing this is to transmit as 
much information as possible as digital data, another is 
to let several- users operate on a number of common- ■ 
frequency channels (truhked channels). In a common, 
trunked system the frequencies can be used 2-7 times more 
efficiently than in conventional systems. At the same time 
the overall investment for the base radio station network 
is reduced or the users can get a more operationally- 
efficient communications system for the same cost. 

In MOB I TEX, digital data (e.g. text and status) can be 
transferred and speech communication can be. established on 
a number of common channels. The fixed network (base radio 
stations and exchanges) are installed and operated by the 
network operator. This part should be regarded as a 
transparent transmission link for data and speech between 
one terminal's output and another terminal's input. The 
user can design his own communications system by adapting 
the design of his terminals to his requirements. The 
terminals use MOBITEX as a communication link between 
them.- 
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2 BASIC REQDIREMEKTS 

The following requirements have formed the basis for the 
development work: 

- the system must be primarily designed for dispatch 
traffic. 

- the changing over from an existing radio network to 
MOBITEX is to be facilitated as far as possible, 

- it must be possible to use the system for both speech 
and text and for other data communication between 
connected units , 

- the system must be transparent for user data, customer 
adaptation. of terminals must be possible, 

- emergency messages from mobile units must be 
..transmitted in plain text, 

- it must be possible to initiate emergency messages from 
a pocket transmitter when outside a vehicle, 

- number dialling must be facilitated and it must be 
possible to call both individuals and groups, 

- the system must keep track of the mobile units so that 
calls can be automatically routed to the correct base 
radio station, 

- communication must be possible between mobile units and 
external networks {e.g. telephone and data networks). 
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3 TRAFFIC FACILITIES 

HOB I TEX provides the facilities for message traffic of the 
store-and-forward type and for traffic via line 
connections (primarily speech) between terminals connected 
to the MOBITEX network and between its terminals and 
external networks (telephone and data networks). 



3.1 SUBSCRIPTION 

A subscription to MOBITEX comprises either a terminal 
subscription, linked to a particular mobile or fixed 
terminal, or a personal subscription which can be moved 
between different terminals (mobile and fixed) . A number 
of various services can be linked to each subscription. 



3.1.1 Terminal subscription 

A terminal subscription-is -linked to a certain terminal 
connected to the network. There are two types: 

- fixed terminal subscription 

- mobile terminal subscription 



3.1.2 Personal subscription 

A personal subscription is not bound to a particular 
terminal but can be moved between different terminals, 
both fixed and mobile. 

The services subscribed to by a personal subscription may 
be limited by the terminal it logs-in to. 

When logging-in a personal subscription, the user notifies 
this to the network with .a login message, including a 
password. The log-in becomes valid when the terminal has 
received an acknowledgement from the network. 

The network considers the subscription logged-in to the 
stated terminal until the subscription either sends a 
logout message or lbgs-in to another terminal. 

A physical terminal can have up to 7 personal 
subscriptions logged-in to it at the same time. 
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3.2 SUBSCRIPTION SERVICES 



3.2.1 Message traffic 

One of the main services in HOB I TEX is sending and 
receiving text and data messages. A message can be a 
status message, a text message, a data message or a HP- 
data message with freely coded data. 

Messages can be both sent and received by: 

* fixed terminal subscriptions 

* mobile terminal subscriptions 

* personal subscriptions 

Group numbers for messages can only receive traffic, not 
initiate. 

If a message does not reach an addressee, e.g. if the 
addressee' s terminal is switched, off , the sender is given 
notification of this. Such messages can be stored in a 
network mailbox and sent to the addressee when available 
again. 

If more text or data is to-be transmitted than can be 
contained in one message, the transmission must be divided 
into several sub-messages. The network does not control 
the order in which the different sub-messages are 
delivered to the receiver. Such a control must be made by 
the terminals if needed by the application. 



.3.2.1.1 Status traffic 

Frequently recurring messages such as "available", 
"engaged", "off to lunch" can be coded to a number which 
is all that is then transmitted. Thus the transmission 
time can be reduced considerably. There are facilities for 
256 different status messages. Coding of the messages is 
carried out by the user. Terminals, both fixed and mobile, 
can be designed to translate the status codes to plain 
text. 



3.2.1.2 Data traffic 

Freely coded user data is transmitted in the form of data 
messages of varying lengths. User data must be formatted 
to complete octets. A data message may contain up to 512 
octets of user data. Coding and decoding of information is 
determined by the user application. 
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3.2.1.3 HP-Data traffic 

Data packets to be used when more than 512 octets should 
be sent and when higher protocols above the Mobitex 
network Layer should be used. Each HP-data packet consists 
of up to 512 octets of user data. 

Two different types of higher protocols can be defined, 
public protocols and user defined protocols, where public 
protocols have been registered and assigned a protocol 
identification number by the network operator. Dser 
defined protocols, on the other hand,. may be used by a 
terminal without restrictions. 

User data must be formatted to complete octets. Coding and 
decoding of information, concerning the higher protocol 
used, is determined by the user and his terminals. 



3.2.1^4 Text traffic 

Data messages in the form of text, coded according to 
national standards, are called text messages. This coding 
permits receiving emergency messages and inter-company 
traffic. 

The maximum text length is 512 characters. 



3.2.2 Speech (line-connected traffic) 

Speech traffic, which is also referred to as line 
connected traffic, differs from other types of traffic as 
a real time link is established between the A and B 
parties. This connection can then be used for transferring 
speech or other analogue signals. 

Line-connected traffic can be exchanged between: 

* fixed terminal subscriptions 

* mobile terminal subscriptions 

* personal subscriptions 

Group numbers for line connection can only receive 
traffic, not initiate. 
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3.2.3 Emergency traffic 

Emergency traffic is a common name for 

- emergency signal/emergency message, 

- emergency acknowledgement, 

- emergency connection. 



3.2.3.1 Emergency signal/Emergency message 

Emergency signals are a type of text message which are 
sent automatically by the mobile terminal after initiation 
from an emergency button in or outside the vehicle or from 
a pocket transmitter when away from the vehicle. The 
emergency signal may contain up to 256 characters. 
A complete emergency message comprises two parts, one 
fixed part of .256 characters which is stored in the 
network as subscriber information and one dynamic part 
which is accessed in the mobile terminal when the 
.emergency signal is initiated. When the emergency signal , 
together with the dynamic part, has entered the network, 
the fixed part, stored in the network, is accessed and 
appended to the dynamic part. The complete emergency 
message is then sent to the emergency receiver terminal 
which is stated in the subscriber information of the 
subscription sending the emergency. 

Emergency signals can be given special priority on the 
radio path, which gives them quicker access than standard 
messages, when necessary. 

The fixed part of the messages stored in the network, 
coded according to national standards for text code, shall 
apply to the dynamic part in the mobile terminal. 

The emergency message is presented in plain text at the 
receiving terminal. The emergency message receiver need 
not therefore have current conversion lists. 

Normally, mobile terminals and personal subscriptions 
logged-in to mobile terminals generate emergency messages. 
Likewise, fixed terminals and personal subscriptions act 
as emergency message receivers. In case other requirements 
are made, any subscription can both generate and receive 
emergency messages. 

When ordering the subscription it is also possible to 
define an alternative emergency message receiver. The 
emergency messages will be sent to the alternative 
receiver when the ordinary receiver manually has ordered 
emergency messages to be re-directed. 

it is also possible to define a rescue centre as, ordinary 
or alternative, emergency message receiver. This means 
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that there will always be someone who takes care of the 
emergency message. 



3.2.3.2 Emergency acknowledgement 

An emergency acknowledgement is a message which is 
manually initiated from the emergency receiver. 

This is used to give the emergency signal transmitter an 
acknowledgement of that the message is taken care of. 



3.2.3.3 Emergency connection 

A fixed terminal subscription receiving an emergency 
message can also initiate an emergency connection. It is 
addressed to the subscription which sent the emergency 
signal. It can be used to establish a speech connection 
between the part initiating the emergency and the 
emergency receiver. The network establishes a bi- 
directional line connection. The design of the mobile 
terminal then determines if the connection is used in . 
either or both directions. 

An emergency connection always has a higher priority than 
a normal line connection. This means that a line 
connection in progress will be disconnected to the benefit 
of an emergency connection at a blocking situation. 
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3.2.4 Group traffic 

A number of terminal subscriptions can be combined and 
allocated a common group number in addition to the 
individual terminal numbers. 

The group message will only be sent to terminals in a 
limited geographical area defined by the stated base radio 
stations together with the fixed terminals for the group. 

Personal subscriptions cannot be included in a group. They 
can, however, generate traffic to groups. 

Subscriptions included in a group receive traffic directed 
to the terminal number, as well as to the group number to 
which they belong. 

A terminal subscription can belong to up to 15 groups, . 
including the All terminals group. 

... The. .group numbers are stored in the terminals, and can' be 
updated from the network. 

Group traffic is divided. into two types, one for messages 
and one for line connection. 



3.2.4.1 Group traffic for messages 

Status, text, data and HP-data messages can be sent to 
this type of group number. 

The message is sent to the fixed terminals and the base 
radio stations stated for the group number. 

This type of message is not acknowledged by the receivers. 
Thus the sender is not quite sure who has received the 
message. To increase safety, the message is- repeated for a 
number of times. 
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3.2.4.2 . Group traffic for line connection 

Line connection can be requested for this type of group 
number (e.g. for speech traffic). 

Connection concerns the base radio stations and the fixed 
terminals stated for the group number. There must be at 
least one base radio station, included in a group. 

At the stated base radio stations, the call is transmitted 
to the group together with a channel change order to a 
traffic channel. The traffic channel is connected in relay 
traffic and the mobile terminals can communicate in 
semi-duplex. 

There is no check of which mobile units that have received 
the call. 
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3.3 SUBSCRIPTION FUNCTIONS 

Each subscription is characterised by the set of functions 
(services) which are included, either automatically 
connected to the type of subscription or optional. 

The following table shows possible (P) functions to be 
launched by each network operator, for fixed, mobile and 
personal subscriptions. 



MOBITEX-function 



Text/HP-data/data traffic 

Status traffic 

Speech traffic (line conn.) 

Password 

Emergency traffic 

Group traffic status/text/data 

Group traffic speech (line conn) 

Partially active 

Data interruption on line conn. 

Mailbox 

External networks 
(telephone, telex, data networks 
etc. individually optional) 



Type of subscrip. 



Designations: FST fixed terminal subscription 
MOB mobile terminal subscription 
PERS personal subscription 



3.3.1 Text/data-traffic 

The subscription can send and receive text, HP-data and 
data traffic. Barring of incoming or outgoing text/data 
traffic is possible. 



Status traffic 



The subscription can send and receive status messages . 
Barring of incoming or outgoing status traffic is 
possible. 
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3.3.3 Speech traffic/line connection. 

The subscription can generate and receive a line 
connection for speech traffic- Barring of incoming or 
outgoing speech traffic is possible. A mobile terminal 
requesting a line connection may be put in a queue, where 
it waits for a radio channel to become available. 



3.3.4 Password 

Passwords provide protection against unauthorized use of a 
personal subscription. The network checks when logging in 
that the correct password according to the subscription 
information is given. The function is mandatory for a . 
personal subscription. 

There is no password for fixed and mobile terminal 
subscriptions. 



3.3.5 Emergency traffic 

The emergency service allows the subscriptions listed 
below to both generate and receive emergency messages. 
They can also be designated as alternative emergency 
receivers. 

- Fixed terminal subscription 

- Mobile terminal subscription 

- Personal subscription logged-in at a fixed terminal 

- Personal subscription logged-in at a mobile terminal 



3.3.6 Group traffic for messages 

Only MOB and FST can be included as members in the group 
and thus accept a group message. All subscription types 
can generate a message to be sent to group. 



3.3.7 Group traffic speech (line connection) 

Only MOB and FST can be included as members in the group 
and thus accept a group connection. All subscription types 
can generate a group connection. 



3.3.8 Closed user groups 

A closed user group (CUG) is a group of subscribers who 
other subscribers can not communicate with. This means 
that traffic between two subscribers not included in the 
same CDG is barred by the network. 
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All types of subscriptions can be included in a CUG and 
the number of members in a COG is unlimited, i.e. it is 
possible for all network subscribers to-be members of the 
same CUG. 



3.3.9 Partially active in MOBITEX 

This function means that the mobile terminal can be 
partially active in MOBITEX, i.e. it monitors the MOBITEX 
network periodically so that it can be used in between 
times in another network or can rest .to save batteries. 

The function means that MOBITEX traffic to the terminal is 
synchroni2ed with the sweep signals from the base radio 
station, appearing at predetermined times. 

The partially- active service is only available for 1200- 
bps terminals. 



3.3.10 Data interruption in a line connection 

This function means that if the subscription is engaged in 
a line connection, it will be interrupted momentarily for 
transmission of any text/data/status messages which are 
addressed to the subscription. Only mobile terminals can 
have this function (data and speech can be sent 
simultaneously to fixed terminals at any time). 



3.3.11 Mailbox 

The mailbox service means that messages, to a subscriber 
who cannot be reached for some reason (e.g. the terminal 
is switched off or the personal subscription is. logged 
out) are stored in a network mailbox. 

When sending a message, the sender can state whether it is 
allowed to be stored in mailbox or not. 

As soon as contact with the subscription is established 
again, the messages in the mailbox are sent automatically 
to the subscription. 



3.3.12 Joint-traffic 

The signalling between the base radio station and the 
mobile terminals includes a network identification. This 
allows different MOBITEX networks to exist in the same 
area and in the same frequency band. It also prevents 
mobile terminals from unnecessarily changing between 
networks (no automatic change of network is allowed). 
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When changing- network, which is done manually in the 
mobile, the frame synchronization is replaced. As a 
result, mobile terminals can only receive roaming signals 
and other traffic from the network currently selected. 

This means that base stations belonging to different 
networks transmit different frame synchronization 
patterns. 



3.3.13 Traffic areas 

The signalling between the base radio' station and the 
mobile terminals includes a also includes an area 
identification used to specify geographical areas. Such an 
area is denoted as a traffic area and is given a unique 
area ID by the network. 

A list of area IDs specify the area a mobile terminal may 
traffic. Outside the specified area, two possible cases 
exist: 

1) the terminal is not operational 

2) the terminal is operational but may be debited a 
different fee. 



When a subscription is registered, the traffic areas the 
terminal may operate are defined. -These area IDs are 
registered in the network subscription record for each 
mobile terminal. The area IDs are transferred to the 
mobile terminal in an MPAK. 

A base station is recognized as a member of a traffic area 
by stating the area ID in the frame head. The area ID is 
specified by 6 bits. Hence, 64 traffic areas can be 
defined within a specific network. 

During the roaming procedure, the terminal will primarily 
evaluate the roaming signals from bases belonging to the 
listed traffic areas. However, other bases may be 
considered in the roaming procedure if the terminal is 
allowed to traffic the areas outside the specified areas 
{see case 2 above). If the terminal lacks a list of area 
IDs, the roaming procedure will evaluate all roaming 
signals. 

The network checks all packets with respect to traffic 
areas. If a terminal should try to traffic an area it has 
not subscribed to, the packets are returned (case 1) or 
forwarded, but with the possibility for the network 
operator to use a different fee ( case 2 ) . 
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3.3.14 External networks 

MOBITEX ia primarily designed and intended for dispatch 
traffic between mobile terminals and their dispatch 
offices and between mobile terminals. The facility for 
traffic between mobile terminals and other telecom- 
munication networks is included as an optional additional 
services. 

Barring of incoming and/or outgoing access to external 
networks, on individual subscriber basis is possible. For 
example, fixed subscriptions as well as personal subscrip- 
tions logged-in to a fixed terminal, can be blocked for 
access to external networks. 



A132SISM 
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3.4 TRAFFIC LIMITATIONS 



3.4.1 Text/data. traffic 



The maximum quantity of user data in a message is 512 
octets. If more data is to be sent, it must be divided 
into several sub-messages. In this case it is recommended 
to use the HP data packet type. The network does not 
control the order in which the different sub-messages are 
delivered to the receiving terminal. 

3.4.2 Line connection 

A line connection in progress can be cleared down at any 
time, by either party and is subject to a time limit, to 
ensure that call lengths are not excessive. Normally an 
. intermittent "hurry up" tone will be inserted in current 
line connections before this happens. 

A maximum period of time for line connections can be 
defined. At blocking situations, line connections which 
have been in progress for more than a specified time may 
be disconnected one by one for the benefit of new calls. 

The line connection can be charged for depending on the 
way it was disconnected. Either normally within the time 
limit, after this time limit when the "hurry up" tone is 
inserted or after the time limit for ^he "hurry up" tone. 
This is defined by the network operator. 

The traffic limitations described above are booth for line 
connections between KOBITEX subscribers, and for line 
connections between a HOB I TEX subscriber and a subscriber 
in an external network. 
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4 CHARGING PRINCIPLES 




HOB I TEX .offers a very flexible system for charging of 
subscribers. 


Mobitex subscription fees 
following categories: 


can be divided into the 



- Non recurring fees 

- Subscription fees 

- Traffic fees 



This classification of different fees is motivated by the 
demand for flexibility in charging. 

The charging principles can be made according to the 
operator wishes. 



Button 



1 

A JM 3133/3 
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For addressing subscriptions and groups the network always 
uses an address which comprises 24 bits, MOBITEX 
subscription number (MAN). This provides 16,777,216 
combinations which must be represented by 8 decimal 
digits. In purely operative terras the terminals can, 
however, be designed to accept abbreviated numbers from 
the operator. The terminals must then convert the 
abbreviated number to a complete MAN before the network is 
called. 

A closed user group (CUG) is given an identity which 
comprises 16 bits. This provides 65,536 combinations. 



Exhibit 2, p. 



Cantel Mobitex~ 



1551 - A 296 5073 Oe 

ets: rss f^rrr 

1990-02-19 J MTSI 



6 NETWORK . STRUCTURE 

The HOB I TEX system comprises a fixed network (base radio 
stations and exchanges) with connected terminals. The 
following describes" the network structure whereas the 
terminals are described in a section of their own later 



6.1 NETWORK HIERARCHY 

The MOB I TEX network comprises base radio stations (BAS), 
area exchanges (MOX), main exchanges (HHX) and the network 
control centre (NCC). These units are called network 
nodes. The following figure is an example of a possible 
network configuration: 




TERMINALS 
( MOBILE and FIXED) 



The mobile terminals are connected to the network via the 
radio channels to the base radio stations (BAS). The fixed 
terminals are connected to the network via fixed 
connections to the area exchanges (MOX). As the base radio 
stations and area exchanges comprise the terminal 
connection points they are designated the "end nodes" in 
the network. 

Traffic handling, i.e. routing of traffic between 
terminals, is carried out in the network up to and 
including level MHX. NCC does not take part in the actual 
traffic handling - it includes an operation and 
maintenance function and also a subscription information 
handler function. 
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6.2 MAIN COMPONENTS OF THE NETWORK 



6.2.1 Base radio stations (BAS) 

The base radio stations constitute end nodes for the 
mobile terminals. They are also switching points for 
vehicle-to-vehicle traffic within the respective radio 
coverage areas. They therefore have the necessary 
information about the mobile subscriptions within their 
radio coverage areas to be able to handle this traffic. 
This is necessary for autonomous operation in the event of 
a line failure to MOX. 

Equipment is installed at the base radio stations for a 
number of radio channels. One of these is used for the 
system channel whereas the others are used as. traffic 
channels for speech or data. The number of traffic 
channels is determined primarily on the basis of the 
anticipated volume of speech traffic. 



6.2.2 Area exchanges (MOX) 

Area exchanges constitute end nodes for fixed terminals 
which are linked to them. They are the switching points 
for traffic between base radio stations and fixed 
terminals. 

The number of area exchanges will depend to a large extent 
on the number and distribution of the fixed terminals 
throughout the country. 

6.2.3 Main exchanges (MHX) 

The main exchanges route traffic between area and main 
exchanges. The main exchanges could be connected in a 
number of various ways, e.g. in a tree or a ring 
formation. 

It is possible to install main exchanges on several"" 
routing levels for trunking reasons, i.e. to save data and 
speech connections. 

6.2.4 Network control centre <NCC) 

The Network Control Centre (NCC) includes an Operation and 
Maintenance function together with a Subscription 
information handler function. 

This is where the subscription information is entered and 
then sent to the main exchanges. 
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The charging information is collected by this unit during 
periods of low traffic. After totalling, the necessary 
basis for accounting is created which can then be sent out 
by another administrative system. 

The operation and maintenance functions consist of 
collecting central alarms and operating statistics, test 
function initiation, setting of operating parameters and 
program loading of all network nodes. 



6.2.5 Connections 

The combination of both data and speech connections in 
MOBITEX , means that digital transmission systems are 
preferable to analog connections between nodes. 

For data connections between network nodes ; two different 
interfaces can be used, either X.21bis together with 
ISO/HDLC or X.25. 

Where possible, the connection between two nodes can be 
split up between different routes, e.g. radio link and 
cable or different cable routes. 
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7 TRAFFIC ROOTING 






7.1 SUBSCRIPTION INFORMATION 




Different types of information about the subscriptions are 
necessary, both static information such as functions 
included and dynamic information such as which base radio 
station the mobile terminal is to use. 




7.1.1 Static subscription information 




Examples of static information: 




- type of subscription, 






- subscription number, 






- services included, 






- the address and fixed part of the emergency message, 




- group numbers of which the subscription is a member ' 




- technical data such as frequency band and radio 
channels available in the terminal. 




7.1.2 Dynamic subscription information 




Dynamic subscription information is such information about 
the subscription which is often changed. This information 
deals with roaming, sequence numbers on the radio path, 
.logging-in of personal subscriptions and 
activation/inactivation status of terminals. 




7.1.2.1 Roaming 






Information about which base radio station to be used for 
a certain terminal is kept within the network and is 
updated by the mobile terminal when moving from one base 
radio station to another. 




7.1.2.2 Sequence numbers 




Messages, which are exchanged between a base radio station 
and a mobile unit, are always given a sequential number by 
the sender. When roaming to a new base radio station, the 
old base radio station sends information about the 
relevant sequence number to the new base radio station 
together with other subscription information. 
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7.1.2.3 • Logging-in of personal subscription 

For a personal subscription to be used it must first 
notify the log-in to the network. This is carried out from 
the new terminal by sending a log-in message to the end 
node. The log-in is registered in the terminal as well as 
in the end node. The relevant base radio station stores 
information about. which terminal the personal subscription 
is using. If the terminal roams to a new base station, the 
old base radio station will send information about which 
subscriptions are logged-in. to the terminal. 

If a personal subscription logs-in to terminal without 
having logged-out from another terminal, the previous log- 
in will be cancelled. 

A personal subscription normally disconnect itself with a 
log-out message. 



7.1.2.4 Activate/Inactivate 

To avoid unnecessary attempts to call subscriptions which 
are not active, the terminals must notify the network when 
they are switched on. Fixed terminals do this immediately, 
after switch on by sending an "active" message. Mobile 
terminals may delay the "active" message so that 
activation can be made on possible user traffic exchanged 
within this time. If no traffic has been exchanged with 
the mobile terminal within this delay period after switch 
on, an "active" message is sent to the base station. 

When a terminal is switched off, it automatically sends an 
"inactive" message to the network. 

If a mobile terminal loses . contact with the network and no 
traffic has been exchanged within a certain time limit, it 
will send an "active" message after contact with the 
network has been reestablished again. 

Group traffic messages will not cause an activation. 

A personal subscription is activated/inactivated at the 
same time as the terminal to which it is logged-in. 
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7.2 ERROR HANDLING 

In a network such as MOBITEX, where the majority of the 
terminals are mobile and communicate via radio, a number 
of phenomena which cannot be considered as pure faults 
occur . 

* An acknowledgement of a message can be missed by the 
unit sending the message. This unit then tries again. 
To avoid a copy of the message being displayed, the 
sender (BAS or mobile terminal) allocates a sequential 
number to all messages. Messages with the same 
sequential number as the previous one are deleted by 
the receiving unit (MOB and BAS respectively). 

* If a subscriber cannot be reached, the message will be 
returned to the sender or will be placed in a mailbox 
with a message to the sender stating this fact. 



7.3 "" RESERVE ROUTES 

The principle is that each node should have a reserve 
route to another node in addition to the ordinary. node. 

If the establishment of a reserve node is unsuccessful, 
the cut-off node will convert to autonomous operation as 
is described below. 



7.4 AUTONOMOUS OPERATION 

When contact with a hierarchically superior network node 
is lost, messages cannot be forwarded upwards in the 
network. Traffic between terminals under the the same 
autonomous node will be dispatched as usual. 

If a mobile terminal which was not under the node when the 
line break occurred roams in, there will be no facility to 
receiving traffic information from higher levels in the 
network. Technical information can then be requested from 
the mobile terminal. 

An attempt to log-in a personal subscription is accepted 
only if the autonomous node happens to have subscription 
information for the subscription concerned. 

A base radio station may in autonomous operation send 
incoming emergency messages as general messages to all 
mobile terminals. 
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7.5 TRAFFIC CONTROL AND OPTIMIZATION 

The algorithms controlling the access to the radio path 
between a base radio station and a fleet of mobile units 
are designed to handle all traffic situations. In order to 
do so, the traffic in the coverage area of the base 
station is monitored to account for short term variations 
in the flow of traffic. 

It is easily understood that if the major traffic consists 
of short "Status" messages, the occupation of the radio 
channel is different from a case with long data packets. 
Things like this must be taken in account when selecting a 
traffic algorithm and setting parameters. 

On a short term basis the access to the System Channel, 
and optional data traffic channels is controlled at the 
base station in order to obtain a high throughput and 
lowest possible transmission delays of the packets. 

-^Jta a long term basis, statistical information derived from . 
the traffic situation in a certain area may influence such 
different' issues as installing more radio channels at a . 
base radio station, raising of data rates on connections 
between nodes, opening of new sites for base radio 
stations or exchanges etc. 



Exhibit 2, p. 59 



Cantel Mobitex- 



1551 - ft 295 5073 Ue 
1990-02-19 J MTSl 



8 TERMINALS • 

A terminal is the equipment used for communication with 
the HOBITEX network. It contains information about 
subscriptions logged-in to it. 

The terminals can be designed according to the users' 
requirements within wide limits. However, terminals which 
are to communicate with each other must be adapted to each 
other e.g. with respect to the coding of data. 



8.1 FIXED TERMINALS 

8.1.1 General 

Fixed terminals are located at offices or dispatch centres 
and are connected to the MOB I TEX network via fixed links. 
Connection is made to the closest area exchange. 

The connection permits tex-t/dafea -traffic and line 
connection at the same time. 

The equipment and the application software at the office 
is normally adapted to the user's special requirements. 

8.1.2 Packet oriented terminals 

To implement a communication between these terminals and 
the MOB I TEX network, special MOBITEX packets are used. .For 
the link layer interface a number of different interfaces 
could be used. 

Messages are -edited and formatted locally in the terminal 
before they are sent to the MOX as MOBITEX messages. 

This group of terminals contains almost unlimited 
possibilities for customer adaptation. The equipment can 
be designed to be used only for MOBITEX communication. But 
it can also be integrated with other computer systems at 
the company. The operator can then use the same equipment 
for MOBITEX communication as for other purposes {e.g. data 
support for error reports, work planning, transport 
planning etc. ) . 
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8.1.3 Character oriented terminals 




Asynchronous terminals work with only one character at a 
time. To handle this type of terminal, there are special 
packet assembly/disassembly units (MP AD.) in the network. 
MP AD contains software which handles the characters from 
the terminal, processes these and creates messages which 
can be handled by the MOBITEX network. In this way, 
inexpensive terminals can be used at offices. 




8.2 MOBILE TERMINALS 






8.2.1 General 






The mobile terminals in MOBITEX are considered as 
communication interfaces which handle signalling and 
procedures on .the radio path and accept and supply 
information from and to the user and any additional 
equipment. 




The mobile terminal can be divided into the following" " 
functional units: 




- radio unit 






- control unit 






- operator's unit 






- peripheral equipment 






The functional units can be integrated in different ways 
in different physical units. 




8.2.2 Radio unit 






The radio unit contains transmitter and receiver. The 
traffic method is' 2-f requency simplex. Full duplex 
operation is possible during line connections (speech) 
except for line connections to groups. However, full 
duplex operation can be restricted or made impossible by 
frequency assignments. 




The radio unit is controlled entirely by the control unit. 
The control functions include selection of transmitter and 
receiver frequencies independent of each other, 
transmitter on/off, noise limiter on/off, signal strength 
level, modulation to transmitter and LF from receiver ecc. 
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Radio units with different HP bandwidths and different 
frequency setting facilities are permitted in the system. 
Limitations on these points will however reduce the mobile 
terminal's traffic facilities in the network, e.g. in the 
form of higher blocking probability than for a fully 
fitted mobile terminal. The user himself must attempt to 
assess these limitations, bearing in mind current and 
future communication requirements. 



8.2.3 Control unit 

The mobile control unit (MCU) contains the hardware and 
software required for radio signalling and to control the 
different inputs and outputs. These are designed for 
connecting peripheral equipment such as operator's unit, 
microphone, loudspeaker, printer, display, key board etc. 



8.2.4 Operator unit 

An operator unit is necessary for the primary manoeuvring 
of the mobile terminal. This can be designed in different 
ways depending on how the mobile terminal is used as a 
whole. The design can vary from the simplest with on/off 
switch, volume control, call button and a limited number 
of status buttons to a complete ASCII keyboard with 
function keys, perhaps integrated -for use with other 
systems in the vehicle. The operator's unit can also be 
integrated with a hand set. 
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8.2.5 Peripheral equipment 

Additional peripheral equipment can be connected to the 
mobile control unit. Its facilities are determined by the 
user in his application and his specification of the 
mobile control unit. 

Future changes and developments will be facilitated if MCO 
is specified with standardized in and outputs. 

A few examples of possible additional equipment are: 

- paper printer, 

- video terminal, 

- LCD display, 

- emergency receiver for receiving emergency messages 
from portable emergency transmitters, 

- cash terminal, 

- holders for code plugs, which can contain personal code 
numbers, personal emergency messages, login sequences 
etc., 

- equipment for automatic vehicle location, 
-• taxi meters, 

- computerized systems, e.g. automatic measurement and 
data systems, 

- bar code reader, 

- credit card reader. 



8.2.6 Serial number control 

The electronic serial number (ESN) is stored together with 
the terminal subscription HAN. The use of this number is 
meant to protect the mobile terminal from unauthorized 
use. 

The network layer include possibilities for the system to 
request and receive information about the ESN from a 
specific terminal. 

The . ESN of the terminal is checked by the terminal itself 
at power on. 
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9 RADIO PATH 



9.1 RADIO FREQUENCIES 

9.1.1 Frequency bands and channel numbering 

The MOBITEX network is not bound to the use of certain 
frequency bands or sub-bands or channels with a fixed 
duplex spacing. This means that a vacant frequency in a 
frequency band can be assigned to MOBITEX without any 
major problems in the network. This assumes however that 
an overall numbering of the frequency channels in the band 
is established and that the mobile units can traffic any 
frequency pair in the entire frequency band {wideband 
stations with full synthesis and 2-frequency simplex 
without linking between the receiver frequency and the . 
transmitter frequency). 

The MOBITEX radio protocol have been proven to work in 
frequency bands from 80 MHz to 900 MHz. 



9.1.2 Channel usage 

The base radio stations work -in duplex while the mobile 
terminals work in two-frequency simplex (semi-duplex). 
However, full duplex operation is possible during line 
connections (speech) except for line connections to 
groups. 

One or more of the channels are used as system channel(s). 
The system channels are used both for system messages, 
e.g. for ordering the mobile terminal to a traffic 
channel, and for handling data traffic. 

In addition to the system channel(s) there are a number of 
traffic channels at each base radio station which can be 
used, for data or speech .traffic. 

At most base radio stations, system signalling and data 
traffic are handled on a system channel and traffic • 
channels are used primarily for speech. At base radio 
stations with considerable traffic, the mobile terminals 
can be ordered to traffic channels for data traffic. 
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9.2 TRAFFIC CAPACITY 

The network throughput for data can be expressed both as a 
maximum number of packet transmitted over a radio path and 
as the maximum number of packets a network node can handle 
per time unit. It is also of interest to express the 
average forwarding time for a message. 

The capacity of the network depends on the software and 
hardware release version. 

The traffic capacity for speech can be estimated by using 
traditional Erlang calculation based on assumptions of 
expected average intensities and durations of the calls. 
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9 . 3 RADIO PROTOCOL 






9.3.1 GEKERAL 






The radio protocol described in this chapter consists of a 
data link layer and a physical layer. It ensures a 
reliable and efficient transmission path between the 
mobile terminal and the base radio stations. 




9.3.2 RADIO DATA TRANSMISSION SPEED 




Both 1200 bps and 8000 bps radio data transmission speed 
can be used to connect the mobile terminals to the MOBITEX 
network . 




9.3.3 FRAME STRUCTURE 






A message is sent in a -frame with the following general 
structure: 




| Frame header | Primary block | .... | Following block.' #n| 




The frame header is included in the frame by the physical 
layer to establish synchronization. It includes the 
network identification (i.e the frame synchronization] the 
base identification number, the area identification and a 
set of control flags. 




To achieve high transmission reliability, the frames are 
divided into blocks where each block is coded. The primary 
block contains control information and the address of the 
mobile terminal. 




The network layer information is put in the following 
blocks, the number of following blocks depends on the 
amount of information to be transferred. 
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9.3.4 BASIC ROLES 

A mobile terminal with no traffic to send, monitors the 
system channel. Traffic to the mobile is sent on the 
system channel, either in the form of a complete message 
or as a channel change order. After a channel change 
order, the message is transmitted or a speech connection 
is established on the new channel. 

A mobile terminal with traffic to send awaits a <FREE> 
signal indicating which terminals have access to the 
channel. Speech connections must be preceded by a request 
for channel access. 



9.3.5 ADDRESSING AND CHOICE OF BASE RADIO STATION 

When a mobile .terminal transmits a message it always uses 
its own subscription number in the primary block. When a 
mobile receives messages it listens for its own subscrip- 
tion ..number .or ... a group number to which it belongs. , 

The base' radio station, is only addressed in the frame 
header, using the base identification number. The mobile 
unit determines itself which base radio station is to be 
addressed when a call is sent. The choice of base radio 
station is carried out with the guidance of the reception 
of roaming signals. The quality of all base stations 
received is monitored by the mobile unit by counting a 
weighted number of roaming signals received from each base 
station. 



9.3.6 REPETITION 

A message that is not acknowledged by the base station 
before the next <FREE> signal, is repeated by the mobile 
terminal. This repetition follows the same rules as the 
first attempt. The maximum number of repetitions allowed 
before the transmission is considered as failed is stated 
in the <SWEEP> signals from the base and defined by 
network operator. 

If the base station gets no response from the mobile 
terminal within a certain time limit the entire message is 
repeated. The maximum number of repetitions allowed before 
the transmission is considered as failed is defined by the 
network operator. 

If the mobile or the base station detects, by a checksum 
calculation, that one or more of the received blocks are 
incorrect and cannot be -corrected, it requests a 
repetition of these blocks. These (selective) repetitions 
are requested until a correct message has been received 
and acknowledged. Short messages, comprising only a few 
blocks, are repeated in whole. 
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9.3.7 MESSAGE SEQUENCE NUMBERS 

Each message to and from a mobile terminal is given a 
sequential number (0-15) by the sender. A message received 
with the same sequential number as the one immediately 
before, is deleted. In this way, a repeated message due to 
the sending unit not detecting the acknowledgement, will 
not be presented more than once to the user. 



9.3.8 CHANNEL ACCESS ALGORITHMS 

To reduce the probability of collisions between mobile 
transmissions, an access method with time slots is used. 
This method is based on the slotted ALOHA algorithm. 

Spontaneous transmission from a mobile unit must only be 
made during a -free cycle. The base station indicates the 
start of a free cycle by transmitting a <FREE> signal. The 
free cycle is divided into slots of equal length. The 

-total number of slots (FREE-SLOTS) and the length of -a 

single slot is stated in the <FREE> signal. 

Mobile traffic initiated by the user before the start of 
the free cycle (MOBILE 1). is distributed at random. A 
random number generator selects one of the random slots 
defined in the <FREE> signal (RND-SLOTS). Transmission 
begins at the start of the selected random slot,' if it is 
still allowed. 



« | FREE | |SIL jACKlj |MSG2| | fREe | ^ 



MOBILEl ImSG11___ 

MOBILE2 ' !ACK2l_ 



Traffic initiated during the free cycle is sent at the 
beginning of the next free slot. 

If two or more messages collide, the base station may be 
unable to read them and no acknowledgement will be 
transmitted. When a new <FREE> signal is sent the mobile 
units which sent the colliding frames will renew their 
attempts, this time (individually) choosing a random slot. 
Before a new <FREE> signal is transmitted, the base 
station may send an outgoing message (MSG 2 to MOBILE 2). 

To prevent a message from being disturbed by transmissions 
from other mobile units, the base station can transmit a 
silence signal (SIL) when detecting the start of a 
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message. With the silence signal, the base station 
withdraws the permission to transmit in the" following 
slots. 



9.3.9 MOBILE FLEET DIVISION 

The access permission in the free cycle can be given to 
parts (subsets) of the mobile fleet according to the 
<FREE> signal to reduce the number of access attempts. 

The address and mask fields in a <FREE> signal (or a 
<SWEEP> signal) are used for a binary' division (1, 2, 4, I 
etc) of the mobile fleet. 

In a <FREE> signal, the traffic type parameter gives 
access only for messages of the traffic types: emergency, 
data and/or speech. This may be changed from the Network 
Control Centre (NCC). 



9. 3. 10 SYSTEM SIGNALLING 

A system channel is used both for system messages and user 
traffic. Periodic sweep signalling is used on all system 
channels to set up system parameters, such as the interval 
between <SWEEP> signals. 

The following figures show some examples of system channel 
signalling: 

| SWEEP | FREE | < 20s | SWEEP | FREE j 



sending 

[FREE | to BASE|FREE[ < 20s I SWEEP I FREE I 

Terminal transmitting mode 

receiving 



from BASE FREE 



SWEEP | FREE | 



Terminal receiving mode 
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9.4 TRAFFIC -HANDLING ON RADIO CHANNELS 



At base radio stations with only a small amount of traffic 
or during periods of low traffic, the system channel is 
the only channel open for data traffic. 

When the traffic load increases on a base radio station it 
is possible to open a local system channel by an order 
from the NCC. The <SWEEP> signals on the system channel 
then orders parts of the fleet of mobile terminals to the 
local system channel to reduce traffic on the system 
channel. A base radio station can operate several local 
system channels. 

If the call intensity from the mobile terminals is too 
great for a system channel, the base radio station can 
open one or more access channels. Calls from mobiles are 
then spread across several channels and the risk of 
collision is decreased. The <SWEEP> signals on the system 
channel includes information about open access channels. 

A set of channels for each base radio station may be 
dedicated for speech connection traffic only. 
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New Roaming Algorithim: 






A new algorithm for roaming and channel software access as been defined by 
ERITEL for implementation in Mobitex System release R12. This algorithm is 
considerably different from (and not backward-compatible) the 1200 bps R4B 
specifications. In quick overview: 




* The mobile measures the received signal strength (in dBu V emf) of signals 
from the base stations instead of counting in ROAM signals. 




* The mobiles uses all received frame heads from the base station in its 
measurement and evaluation, not just ROAM signals. 




* A new scanning mode is implemented, for which base stations' system 
channel must be continuously on. In this mode of operation, the mobile 
should scan about 10 channels per second. 




Normal System. Channel Monitoring Procedure: 

When the mobile has contact with a base station, it monitors the current system 
channel, and also scans other system channels given by the network (in the 
<SVP> frame), the procedure can be diagrammed thus: 




<SVP> 


<SVP> 




I 

j mmmmmmmmmmmmmmmmmmmmm | s 


sssssssssssssssss|mmmmmmmm | 
e 




where •mmmmmm..* means monitor the current system channel 
•sss..." means scan other system channels(s), and "e" means 
evaluate the received signals. 
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The length of the period during which the mobile monitors other system 
channels is given in the <SVP> frame as SCAN-TIME. The starting time of the 
'sss..' sequence is different for different groups of mobiles, based on their 
having an odd or even MAN. as follows: 




scan start (odd) = TIME TO NEXT - 10ms - 2* SCAN TIME 
scan start (even) = TIME TO NEXT - 10ms - SCAN TIME 




where TIME TO NEXT is the time to th 
<SVP> frame. 


e next <SVP>, as given in the last 




The mobile has two different ways to evaluate system channels other, than the 
current system channel - FRAME MODE and CONTINUOUS MODE. Which 
mode the mobiles should use is given in the <SVP> frame as RSSI_PROC. 




* In FRAME MODE, the mobile measures the signal strength during all frame 
heads. This mode is similar to that used for monitoring the current system 
channel. In this mode the mobile has to stay on the same channel for 
~ approximately one second (and perhaps longer)- in order to receive at least ■ 
one frame head. The length of time over which to make measurements Is 
given in the <SVP> frame as RSSI_PERIOD. 




* In CONTINUOUS MODE, the mobile measures the signal strength during a 
short period (typically 100ms) on each channel. Here, the mobiles do not care 
whether it receives frame heads or any other type of traffic; it is measuring the 
carrier, which must be continuously on. Note that in this mode, the mobile 
does not initially know the Identity of the base station whose signal it is 
monitoring, since it is not reading frame heads. 




Quick Scanning Procedure: 






When a mobile loses contact with the network it enters a 'quick scanning" 
mode. In this mode the mobile monitors each likely channel for a short period. 
The channels are scanned in the following order: 




1. The channels in the current (neighbour) list given in the <SVP>. 

2. The channels in the current list stored in PROM. 




At the system operator's discretion, the d 
by a shorter list (called the ■temporary d 
mobile's usual operating area 


efault list may be temporarily replaced 
efault list') of system channels in the 
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The mobile scans "n" channels from the above scheme (where "n" is a number 
defined by the system operator - typically 10), and then monitors the last used 
system channel again. It then scans 'n' new channels from the lists and returns 
to the last used system channel, and so oa When all the channels from both 
the lists have been scanned, cycling repeats over the default fist only with 
periodic returns to the last used system channel. When a measured channel 
has a satisfactory signal strength (as given by GOODJ3ASE in the <SVP>), the 
mobile continues .to evaluate this channel for a few seconds (typically 3) before 
finally selecting it as the new system channel. In the case of CONTINUOUS 
MODE operation, the mobile must at this point acquire and examine one or 
more frame heads in order to determine whether or not it has evaluated a valid 
system base station. 

If the mobile is able to use the CONTINUOUS MODE of scanning as described 
above, the scanning of each channel takes about 100 ms ( including channel 
switching time). The last used system channel is therefore examining every 
second and the recovery time from a temporary cutoff (tunnel, elevator, garage, 
etc.) is reduced dramatically ■. If the system operator has chosen to use the 
FRAME MODE method, the time for "getting back to the last used system"' 
channel is still much shorter for the old (R11) method, but significantly longer 
than for CONTINUOUS' MODE operatioa 

Criteria far Leaving the Current Base: 

The mobile leaves the current system channel and starts the roaming procedure 
in four cases: 

1. The signal level of the current base isloo low (below the values of BAD BASE 
from the <SVP>). . _ . 

2. Another base (BEST.BASE) has a signal strength that is higher than that of 
the current base, and the difference is greater that the value BETTER _BASE 
given in the <SVP>. This is typically 10-15 dB. Before the move takes place, 
the signal strength from 'BEST_BASE", averaged from'frame heads measured 
during the next sweep period, still must fulfill this criterion. 

3. The mobile has made MAXJREP retransmissions without receiving an 
acknowledgement from the base. MAXJREP is also given in the <SVP> 
frame. 

4. The mobile has not received a valid <SVP> frame within two <SVP> periods. 
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Summary of information in the <SVP> fr 


gme: 




The following information relating to the roaming procedure is provided to the 
mobile within a <SVP> frame (subtype 1): 




RSSI PROC - states the method of the signal strength measurement 
0= FRAME. 1 = CONTINUOUS. The default is FRAME 




RSSI_PERIOD - The time used by the roa 
received signal strength. 
(0-255) * 20 ms. The default is 2960 m 


ning algorithm, over which to average 
s. 




SCANJIME - The length of the period during which the mobile scans other 
system channels. 
(0-255) * 100 ms. The default is 3000 ms (3 seconds). 




BAD-BASE - The signal strength from the current base that is just satisfactory 
for use. 

(0-255) dBuV emf. The default is 15 dBuV emf. 




GOODBASE - A satisfactory signal strength to accept for a new base selection 
as current basa 
(0-255) dBuV emf. The default is 15 dBuV emf. 




BETTER_BASE - The signal strength improvement in dB, above which the 
mobile should switch to a new base from the current base. 
(0-255). The default is 10 dB. 




TIME_TO_NEXT - The time in seconds to the next <SVP> frame. 
(0-255)rThe default is 10 sec. 




MAXJREP - The maximum number of repetitions allowed for unacknowledged 




messages. 

(0-255). The default value is set by the system operator. Canter's default value 
is 5. 




Other Information: 






The RSSI signal from the mobile transceiver should be able to indicate signal 
strength over the range 0-50 dBuV emf. OdBuV emf corresponds to 113dBm 
(assuming 50 ohm impedance). The time constant of the RSSI signal from the 
transceiver should be 1 ms. and the mobile should sample the RSSI signal with 
a frequency of 1000 samples per second and obtain the samples from which 
to derive average RSSI. 


S, P ,o= 
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References: 

Chapter 6 discusses scanning procedures in more detail. 

Chapter 16 pages 17-23, discusses the roaming procedure in more detail. 

Chapter 18 page 17, gives information on the signal strength indication to be 
provided by the mobile receiver. See also page 14 of chapter 17. 

The <SVP> frame is detailed in Appendix A of Chapter 16, pages 28-34. 
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Terminal specification 

General description of terminals 



SUMMARY 

To the MOBITEX network fixed and mobile terminals can be 
connected. 

Fixed terminals are connected via a line interface whereas 
mobile units are connected by a radio interface. Layer 
division has been applied to the definition of the 
terminal's functions. 

The upper layers are common to both types of terminals 
whereas the lower layers are available in two versions, 
one for fixed terminals and one for mobile terminals. 
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1 IMTRODOCTION 



1.1 GENERAL 

The term terminal refers to a physical unit which can be 
connected to the MOBITEX network. 

There are two types of terminals: 

Fixed terminals which are connected via separate 
line interfaces for data and voice. 

Mobile units which are connected via a radio 
interface. 

Communication- through the network is done with packets. for 
both terminals. The designation message (MPAK) for this 
packet also appears in the set of documents. 



The . 

MOBITEX 

network 




Radio interface 



Base 
radio 
station 



Mobile 
Terminal 



u 



Line interface 



Fixed 
terminal 



Area 



I I i 



Data 



ex- 
change 



Voice 
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1.2 DIVISION INTO LAYERS IK MOBITEX 



TERMINAL A THE NETWORK TERMINAL B 

Application < ,- > 

Network 

•Link 

Physical | 1 



The physical layer and the link layer separate the 
terminals. The network layer is identical for both types 
of terminals. In the superior layer, the application 
layer, MOBITEX makes demands on the handling of certain 
addressing methods. The requirements which are demanded in 
the application layer are identical for both types of 
terminals. 

In certain applications, the peripheral equipment is 
connected to the terminals. We recommend certain 
interfaces for connection to such equipment. See- reference 
Rl-19 for further information. 

A terminal with peripheral equipment connected can be 
symbolized according to the following model: 

EQUIPMENT TERMINAL THE NETWORK 

Application 
Network 
Link 

Physical 
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2 FIXED TERMINALS 

A fixed terminal is connected via a line interface and a 
voice interface to. the MOBITEX network. The terminal 
communicates with exchanges which constitute the network's 
end nodes for fixed terminals. 



3 MOBILE TERMINALS 

A mobile terminal is connected via a radio interface to 
the MOBITEX network. The terminal communicates with base 
radio stations -which constitute the network's end nodes 
for mobile terminals. It is up to the mobile terminal to 
select which base radio station to belong to at the 
particular time by continuously listening for addresses 
for adjacent base radio stations. 
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4 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-19, 4 



Below are the reference designations listed. 



Reference Section 

Rl-01 Arrangement of the documents 
Rl-02 • MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals' 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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UST OF ACRONYMS 
USED IN SPECIFICATION 

Most of the acronyms used In the Mobitex Documentation are of Swedish origin. 
For convenience of readers all these acronyms have been listed alphabetically 
and a pertinent explanation provided. The most common are described in this 
documentation with English acronyms, therefore whenever there is a risk of 
misunderstanding, use this guide for translation/explanation. 

Swedish/English Explanation 



— yjn 




AAT 


Ghanae access reauest SDeech 


ABD 


Access request data ' 


ABL 


Access request, emergency 


ACT 


Access request, speech 


ACK 


Acknowledgement 






ANS 


American National Standard Institute 


ASCII 


American Standard Code for Information Interchange 


ATD 


Access permission, data 


ATL 


Access permission, emergency 


ATT 


Access permission, speech 


BASE 


Radio Base station 


BBT 


Change base station, speech 


BKD 


Change channel, data 


BKE 


Base station control unit 


BKT 


Change channel, speech 


BMON 


Base Contact Monitoring 


BPSK 


Binary phase shift keying 


CODE 


Coding and Readout 


DCOD 


Input and decoding 


EBC 


Computer rack 


EBR 8/9Q0 


Radio rack 


EEPROM 


Electrically Erasable PROM 


FRI 


Free Signal 


FST 


Fixed terminal subscription 


GMSK 


Gaussian minimum shift keying 


HDLC 


High-level data link control 


IFRA 


Processing Incoming Frame 


iSI 


Intersymbol interference 


ISO 


International Standards Organization 


KKE 


Channel control unit 


LKE 


Line concentrator unit 
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Swedish/English 


Explanation 


Acronym 




USB 


Least Significant Bit 


MAN 


Terminal subscription number 


MASC 


Mobitex asychronous communication protocol 


MCU 


Mobile control unit (as part of modem) 


MFL 


Personal subscription 


Ml 


Modulation Index 


MOB 


Mobile terminal subscription 


MOX 


Local exchange 


MPAD 


Mobitex packet assembly/disassembly 


MLE 


MOX line concentrator unit 


MOA 


Mobitex Operator Association 


MPAK 


Mobitex packet 


MRM 


M-Frame 


MSB 


Most Significant Bit 


MSE 


MOX control unit 


MX 


Main exchange 


NACK 


Negative acknowledgement 


NAM 


Number assignment module 


NAT 


No access permission, speech 


NCC 


Network control center 


NSC 


National system channel 


OCTET 


Byte (8 bits) 


OFRA 


Processing Outgoing Frames 


OSI 


Open System Interconnect 


PADS 


X25 packet assembler/disassembler 


PAHA 


Packet Handling 


PERS 


Personal Subscription 


POT 


Plain Old Telephone 


PROM 


Programmable read-only memory 


PS 


Personal Subscription 


RACK 


Request for repetition of the last sent ACK 


RAM 


Random Access Memory 


REB 


Repetition Request 


RES 


Repetition Reply 


RMD 


RAM Mobile Data 


ROSI 


Radio Signalling Protocol (RSP) 


RSSI 


Radio Signal Strength Indication 


SACK 


SENS Achnowledgement 


SENS 


Link Layer Control 


SVP 


Sweep Signal 
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Explanation 



TEL Public switched telephone network com. unit 

TST Silence order 

UT6 Mobile Unit Output Port Identifier 

VCO. Voltage controlled Oscillator 

VKT Wait for channel, speech 
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ABBREVIA' 


nONS USED IN 






SPECIFICATIONS 




SWEDISH/ENGLISH 

1 a 


EXPLANATION 




ACTIVE 


Terminal active 






Conn. Req. w\additionaI info fast 






Conn. Req. w\additional info 




AREAUST 


List va 


lid area IDs 






Terminal active for the first time 




GLOOPOFF 


Circuit Loop Test End 




CL00PON 


Circuit Loop Test Start 




CONFAST 


Connection Request Fast 




CONGRA 


Connection Request Granted 




CONORD 


Connection order for group call 






Ready for connection 






Connection Request 




CSUBCOM 


Circuit switching for subscriber and emerg/epmm. 






Terra not permitted to send use traffic 




UloUON 


Discor 


inection of connection 






Data Terminal Service Communication 




ESNINFO 


Electronic Serial Number Information 




ESNREQ 


Electronic Serial Number Request 




EXTCONREQ 


Extern 


al Connection Request 




FLEXLIST 


List of personal subscription MAN'S 




FLEXREQ 


List of Pers. Subscription MAN request 




GROUPUST 


List of Group MANs 




INACTIVE 


Terminal not active 




INFO 


Terminal Information 




INFOREQ 


Terminal Information request 




UNEOFF 


Line Connection Off 




LINEON 


Line Connection On 




UNSEL 


Line « 


jlected 




UVE 


The te 


rminal may send packets again 




LOGINGRA 


Login Request Granted 




LOGINREF 


Login Request Refused 




LOGINREQ 


Login Request 




LOGOUT 


Logout 




LOGOUTORD 


Logout order 




MPAK 


Mobitex Packet 




PSOSCOM 


Packet switched emergency communication 




PSUBCOM 


Packet switched subscriber communication 




ROAM 


Roaming Message 




ROAMORD 


Roaming Order 




SOS 


Emergency signal 


Hero.: 
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SWEDISH/ENGLISH EXPLANATION 

SOSACK Emergency Acknowledgement 

• SOSCONFAST Emergency Connection Request Fast 

SOSCONREQ Emergency Connection Request 

SOSRX Cancel Emergency re-direction 

VICESOSRX Re-direction of emergency messages. 



Page MTS 03A.5 



Exhibit 2, p. 87 



•I 




Exhibit 2, p. 88 



TERMINOLOGY 1(5) 



ET/SYS MOt 


'eT/SYS MOtT""" 


sr*: 1 — ' i 

0033 - LZBA 703 1001 Oe 


ET/SYSC ^stt^TT" 


a^.a*. lb. |=-, f-t 
1990-02-16 E |MTS04.1 


Cantel Mobitex- 


MOBITEX 

Terminology and abbreviations 



SUMMARY 

This document includes the terminology and abbreviations 
used in the terminal specification. 
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1 TERMINOLOGY 

The following list gives certain specially defined terms 
used in the MOB I TEX Terminal Specifications. 

The terms are listed in alphabetical order. 



A-PARTY 



BASE RADIO STATION 



The originating unit of the message 
or the line connection, i.e. the 
calling part. 

MOB I TEX area exchange. Constitutes 
the end node for fixed terminals. 

The intended receiving unit of the 
message or the line connection, i.e. 
the called part. 

A base radio station is a network 
node which constitutes a link between 
a number of mobile terminals arid 'the 
MOBITEX network. A base radio station 
transmits traffic on one or more 
radio channels. 



CIRCUIT SWITCHED 
CONNECTION OR 
LINE CONNECTION 



FIXED TERMINAL 



MAIN EXCHANGE 



A circuit switched connection or line 
connection is a zeal time connection 
between terminals. 

The traffic over a line connection is 
normally speech communication. 

In the MOBITEX network there are 
special gateways to other public 
networks such as the datex network, 
the telex network and the data packet 
network . 

A fixed terminal is equipment 
connected to MOBITEX by a leased line 
connection. 

The equipment possesses a Fixed 
Terminal Subscription and can also 
belong to one or several group 
numbers. In addition, one or more 
transferable subscriptions can be 
logged in to the terminal. 

MOBITEX main exchange. Connects the 
area exchanges. 
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MOB I TEX TEXT CODE 



A mobile terminal is equipment 
connected to HOB t TEX via a. radio path 
to a base radio station. 

The equipment possesses a Mobile 
Terminal Subscription and can also 
belong to one or several group 
numbers. In addition, one or more 
personal subscriptions can be logged 
in to the terminal. 

Coded character set for the data 
interchange, according to national 
standard. 



USER TRAFFIC 



Consists of a subscription handler 
part and a operation and maintenance 
part. 

User traffic is the messages 
transmitted between terminals 
connected to MOBITEX. There are user 
messages with different characterist- 
ics. These are differentiated 
according to different traffic types. 



Bildiort 



"EST 
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2 ABBREVIATIONS 

The following abbreviations are used in MOBITEX terminal 
specification. Most" of the abbreviations are explained in 
the terminology chapter. 



BAS 


Base radio station 


PST 


Fixed terminal 


MAN 


Subscription number 


MHX 


Main exchange 


MOB 


Mobile terminal 


HOX 


Area exchange 


NCC 


Network control centre 


PERS. 


Personal subscription 
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Terminal specification 
References 



INTROPaCTIOH 

The reader should have a number of documents and 
publications at hand, referred to in the terminal 
specification. This document lists the necessary 
references. 

Note; Internal references, i.e. to other sections in the 
Terminal specification, are described in section 
Arrangement of the documents. 
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1 CCITT RECOMMENDATIONS 

The following CCITT recommendations are referred to in 
this set of documents: 

V.10 Electrical characteristics for unbalanced double 
current interchange circuits for general use with 
integrated circuit equipment in the field of data 
communications . 

V.ll Electrical characteristics for balanced double 

current interchange circuits, for general use with 
integrated circuit equipment in the field of data 
communications . 

V.24 List of definitions for interchange circuits 

between data terminal equipment and data circuit 
terminating equipment. 

V.28 Electrical characteristics for unbalanced double 
current interchange circuits. 

V.52 Characteristics of distortion and error-rate 
measuring apparatus for da'ta transmission. 

X.l International users of service in public data 

networks. 

X.21'" (X.21 bis) Dse on public data networks of data 
terminal equipment (DTE) which is designed for 
interfacing to synchronous V-series modems. 

X.24 List of definitions for interchange circuits 

between data terminal equipment (DTE) and data 
circuit terminating equipment (DCE) on public 
data networks. 

X.25 Interface between data terminal equipment (DTE) 
and data circuit-terminating equipment (DCE) for 
terminals operating in the packet mode and 
connected to public data networks by dedicated 
circuit. 

X.26 (Refer to V10) 

X.27 (Refer to V10) 

The above recommendations are found in: 

CCITT' Recommendations Volume VIII (Fascicle VIII. 1 - 
VIII. 3) from Vllth Plenary Assembly 1980 (Yellow Book). 
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In addition, there are references to the following CCITT 
recommendations : 



Psophometers , apparatus for the objective 
measurement of circuit noise. 

. CCITT Recommendation Volume V (Telephone 
transmission quality) from Vllth Plenary Assembly 
1980 (Xellow Book) 



2 OTHER INTERNATIONAL STANDARDS 

ISO 646 Data representation - coded character 

set for the data interchange. 
National additions to be used are 
stated in reference Rl-06. 

ISO 2110— Data communication - 25 pin DTE/DCE 

interface connectors and pin 
assignments. 

ISO 3309-1984 (E) Data communication - High-level data 
link control procedures - Frame 
structure. 

ISO 4335-1984 (£) Datacommunication - High-level data 

link control procedures - Elements of 
procedures 

ISO 4903-1980 (E) Data communication - 15 pin DTE/DCE 
interface connectors and pin 
assignments . 

ISO 7809-1984 (E) Information processing systems - Data 
communication - High level data link 
control procedures - Consolidation of 
classes of procedures. 

GA27-3004-2 IBM General Information - Binary 

Synchronous Communication . 

CEPT Recommendation T/R 24-1 

Recommendation for Radio equipment 
(Only a draft is available, at the 
time of publishing of these 
specifications.) 
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3 NATIONAL REGULATIONS FOR RADIO EQUIPMENT 

Regulations to be used for national type approval are 
stated in reference Rl-06. 



A 232 5153/3 
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4 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the. terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. 



Rl-06, 4, 5, 



Below are the reference designations listed. 

Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 ■ General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer . 

Rl-U Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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Network Operator Information (Canada) 
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1. INTRODUCTION 

This chapter includes requirements that are specific to the design of 
equipment for use on the Cantel Mobitex network in Canada. They also 
apply to Equipment to be used in the United States on either a "roaming 
to U.S. basis", or on a subscription in the U.S. 

The sections headings in this chapter describe technical requirements, 
which are either brand new. or have been touched briefly in other 
chapters of the specification, and cross referenced to this Chapter 6 for . 
a more detailed explanation. 
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2. CANTEL NETWORK ASPECTS 

This section specifies the network capabilities and parameters that are 
specific to the Cantel Mobitex network. 

2.1 SUBSCRIPTION FUNCTIONS SUPPORTED 

The subscription functions supported by Cantel are as indicated in the 
following table: 

Subscription Type 
Mobitex-Function FSTMOEPERS 
Text/Data-Traffic * * * 

Status Traffic * * * 

Password * 
Alert Message Service * * * 

Group Traffic/Text/Data * * 

Mailbox * * * 

External Networks * * 

Designations: FST = Fixed Terminal Type 

MOB = Mobile Unit Type 
PERS= Personal Subscription 

2.1.1 ALERT MESSAGE SERVICE 

Alert Message traffic may be generated or received by any subscription 
•type (fixed terminal, mobile unit; personal login at fixed terminal, and 
personal login at mobile terminal). Any of these subscription types may 
also be designated as an alternative Alert Message Receiver. 

2.1 3. MOBITEX TEXT CODE 

The text code used for TEXT TRAFFIC and EMERGENCY MESSAGES in 
the Mobitex Network Is ANSI X3.4-1977 (which is derived from ISO 646 
with national extensions). Each character is represented by one octet 
consisting of the 7-bit ANSI X3.4 code with the eighth bit set to zero. 

Z2 MAN NUMBERING PLAN" 

The Mobitex network subscription address is based on a 24-bit number 
known as the MAN number. 
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The MAN numbering plan for Cantel is partitioned as follows: 




MAN Number Usaqe 






0 Not used 

1 . MOBITEX Network 

2 - 6 External Networks 

7 All Terminals MAN 

8 - 20 External networks 

21 - 99,999 Reserved for future use 
100,000 - 16,777,215 Subscriptions and groups 




Specific assignment of External networks will be determined later. 




The MAN range allocated to subscription (> 100,000) will be further 
partitioned to facilitate network administration and joint traffic with 
other Mobltex networks. 

Cantel will use MAN numbers in the range 2,000,000 - 2,999.999. 




2.2.1 JOINT TRAFFIC 






Unique frame synchronization patterns are assigned to each Mobitex 
network (see Sect 4.1), so as to preclude automatic switching 
between networks. However, mobile terminals intended for use in 
both the US and Canada must be designed to allow manual 
switching between the RMD and CANTEL networks. This network 
switching capability requires that the mobile unit permanently store 
all required synchronization- patterns. Multiple channel default lists 
must also be accommodated in such mobile terminals. 




Actual Internetworking between RMD and CANTEL is planned to be 
implemented at some future date. 
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2.3 HP-DATA PROTOCOLS APPROVED BY MOA 

The network allows up to 255 different higher level protocols for use 
• with HP-Data Protocols 1-127 will de defined by MOA and supported 
as needed by Cantel. At the present time, no HP-Data codes have 
been assigned. Protocols 128-255 are free to be defined on a per 
application basis. 

24 NETWORK MESSAGES 

Messages received by the mobile terminals include a traffic state". 
For all non-zero states, it is required that both the decimal value (0- 
7) and the traffic state' and its meaning be presented to the user in 
plain English text as indicated In R1-09 (Sect. 3.2.3) and R1-08 (Sect 
2.5) 

2.5 CHARGING PRINCIPLES 

The Canada tariff for users of the Mobitex network is stated 
elsewhere and is not part of this specification. 

26 ACCEPTANCE TESTING 

Equipment to be used on the Cantel Mobitex network will be tested 
by Cantel In this specification, and certified as satisfactoiy for use on 
the network. 



FIXED TERMINAL INFORMATION 

BIT RATES AND PROTOCOLS FOR FIXED TERMINALS 

The bit rates for different ffred terminals interfaces supported by tl 
network for different standard protocols is as follows: 

Terminal Interface: Supported Bit Rates (Kbps): 

HDLC 2.4. 4.8. 9.6. 

X25 2.4, 4.8, 9.6, 

MASC 1.2 24 
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3.2 ELECTRICAL REQUIREMENTS 

Fixed terminals shall be designed to operate with standard line voltages 
found in Canada 

Fixed terminal equipment that operates from AC power must meet all 
relevant CSA regulations, be tested by the CSA and bear a specified CSA 
label. 

3.3 SPECIFICATION OF UNE CONNECTION 

Access lines between fixed terminals and the Mobitex network will 
generally be provided by a third party telecommunications vendor. Fixed 
terminals and associated data communications equipment will necessarily 
meet the specifications of these telecommunications vendors. 



4 MOBILE TERMINAL INFORMATION 

4.1 NETWORK IDENTIFICATION NUMBER 

Network identification makes it possible to have different Mobitex networks 
operating in the same area, on the same frequency band, without arbitrary 
and uncontrolled roaming of mobiles and portable units between base 
stations on the different networks. (For example, RAM Mobile Data in the 
U.S. and CANTEL in Canada will have Mobitex networks in the same 900 
MHz SMR band, and uncontrollable roaming between these two networks 
■is undesirable.) The particular network within which unit is to operate is 
specified by means of the frame synchronization pattern of the frame head 
in the physical layer of the radio protocol (bits 17-32). These pattern are 
•assigned and administered by the Mobitex Operators' Association (MOA). 
The patterns are specified below. 



ORIGINATOR 
Mobile/Port. 



BIT NUMBER 



NETWORK 
CANTEL, Canada 



1100010011010111 
1100010011010111 



1 01 1 01 00001 1 001 1 RMD, U.S. 
1011010000110011 



The identification number to be used by the mobile unit may be selected 
by a switch on the unit or by other means. 
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4.2 AREA IDENTIFICATION NUMBER 






The area identification number is also a part of the frame head In the 
physical layer (bits 39-44), and is used to designate a particular group of 
base radio stations in a particular operating area of the Cantei Mobitex 
network. A maximum of. 14 operating areas will be defined in Cantei 
Mobitex network. The mobile must be capable of storing an -operation 
allowed" list of these numbers in non-volatile memory. The binary area 
identification "0* designates ability to operate in all areas of the network. 
Area identification "256* excludes the mobile from operation in any area, 
l.e. it is in monitor mode only. 




Specific operating areas will be designated and identified at a later time. 




4.3 ELECTRONIC SERIAL NUMBER 






Electronic Serial Number (ESNs) are used as a security measure in mobile 
and portable units to protect the system from unauthorized use and to 
help identify stolen equipment A unique and unalterable ESN must be 
permanently affixed to the chassis (case ) of each individual mobile and 
portable unit manufactured for use with the Cartel Mobitex Network. 
Before a mobile unit is accepted by the network, it transmits its electronic 
serial number (as part of the BORN message) to the network, where it is 
checked against the serial number stored there in association with the 
MAN. 




The format of the ESN. which is also transmitted as part of ACTIVE and 
•ROAM messages from the mobile, is as follows. 




MSB 

32 25 24 


LSB 

19 18 1 




Ill II 

| Mfg.Code | . | Reserved | j Serial number| 




The 32-bit ESN is divided into three fields, with bit 1 the least significant 
bit (LSB) and a bit 32 the most significant bit (MSB). There is an 18-bit 
serial numbers field (bits 1-18), a. 6 bit reserved field (bits 19-24), and an 
8-bit manufacturer's code field (bits 25-32) 




The manufacturer's code will be assigned by Cantei. The manufacturers 
may subdivide their serial number fields for their own convenience; a total 
of 262,144 combinations are available. The reserved field is for future use 
to provide additional capability for the serial number of model number 
representation. Manufacturers may wish to apply for additional ESN space 
at a later time; until then, the reserved field should be set to zeros. 
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The ESN is included in octets 9 through 12 of the BORN. ACTIVE and 
ROAM messages. The MSB of the ESN is bit 8 of octet 9, and the USB 
is bit 1 of octet 12. The ESN must also be furnished by the mobile in an 
ESNINFO message, in response to an ESNREQ message from the 
network. 

4.4 RADIO FREQUENCIES 

This section contains radio parameters (frequency plan, channel 
numbering and system channels) specific to the Cantel network. 

4.4.1 DEFINITION OF FREQUENCY BAND 

The frequency band Information is the band in which the mobile terminal 
is working. The Frequency Band Information (FBI) designation for Cantel 



FBI = 4, which corresponds to 900 MHz and 8k bps. 

This information is used by the network when the mobile terminal sends 
MPAK INFO to the network. 

Further Information: R1-09 

The base station uses the frequency band information in certain radio 
frames. 

Further Information: R1-16. Appendix A, Frames 

4.4.2 DEFINITION OF TERMINAL TYPES 

The terminal type information is used to separate terminals with different 
functionality. 

The Terminal Type Information (TTI) associated with Cantel is: 
TTI = 3, meaning terminal type 3 

This information is used by the mobile terminal when sending MPAK INFO 
to the network. 

Further Information: R1-09 
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4.4.3. CHANNEL NUMBERING AND FREQUENCY PLAN 

The radio channels used for Mobitex communications between mobiles 
and base stations are allocated by the DOC from 896-901 MHz band for 
mobile transmit and from the 935-940 MHz for base station transmitfmobile 
receive). Each mobile transmit is paired with a base station transmit 
channel exactly 39 MHz higher in frequency. Thus whenever a base 
communicates with a mobile, and transmits for example on 936.2625 MHz 
(Channel 3701, which is the first channel In Group F), the mobile must 
transmit to that base station only on 897.2625 MHz, which Is Channel 581 
and is precisely 39 MHz lower in frequency. 

Figure F-1 shows the channel number, the base station transmit 
frequency, and the mobile transmit frequency, within this allocation. It also 
shows a letter designation indicating the block to which each channel 
belongs. The channels within any group are spaced exactly 12.5 Khz 
apart. The frequency of a channel may be calculated by the formula. 

Frequency in MHz = 890 + 0.0125 (channel number) 

Note that the channel numbers given in Figure F1 have been assigned by 
ERITEL and are known as "Mobitex Channel Numbers". They do not 
correspond to channel numbers assigned by the DOC or the FCC in the 
United States. However, since the Mobitex system will communicate 
frequency information to mobile and portable units by using the Mobitex 
Channel Numbers, these channel numbers must be recognized and 
associated with the corresponding frequencies by the units. 

It Is important to note that although current Cantel MOBITEX frequency 
plan associates transmit and receive frequencies and channel numbers 
in fixed pairs (the paired frequencies are 39MHz apart), the design of the 
mobile unit transceivers should not preclude the use of transmit and 
receive frequency pairs with various frequency separations. In the future, 
it is not unlikely that mobile units will be required to operate with 
transmit/receive frequency pairs selected from any of the allowable 
frequencies in Figure F1 In order to permit optimization of overall system 
performance under various circumstances. 



4.5 RADIO EQUIPMENT 

4.5.1 NATIONAL REGULATIONS 

Mobile Terminals must comply with all regulations published by the 
Department of Communications relating to equipment used in this service. 
This includes, but is not limited to RSS 122. A manufacturer must design 
the equipment to or in excess of these radio standard requirements. 



Page MTS 06.10 



Exhibit 2, p. HI 




Exhibit 2, p. 112 




Exhibit 2, p. 113 



Cantel Mobitex- 


^ — i j 

E=m he; prr^ ■ 




jij j[ . 


i 

! 

j 


i 














ii i|p 

i liiji 
II lit 








r ! " 




I 





Exhibit 2, p. 114 





Cantel Mobitex- 


— r 1 — 




»~ 3 «. r*rn; — 




4.5.2. OUTPUT POWER - MOBILE UNITS 






The units must be capable of operating at various power levels as 
designated by the system in the TXPOW parameter in the <SVP> frame 
from the network. The required levels are: 




OUTPUT POWER dB BELOW FULL POWER 

10 W o {Maximum power) 

4W 4 

1.6 W 8 

0.63 W 12 

0.25 W 16 

0.10 W 20 




The tolerance on output power teve 


s shall be + 2.0 dB. 




4.5.3. POWER CONTROL - MOBILE UMTS 




In addition to exercising output power control as mandated by the network 
in the TXPOW parameter, mobile units must automatical^ reduce power 
level maximum output based on the average received signal strength 
indication (RSSQ from the current base (as measured during the normal 
system channel monitoring procedure associated with roaming). This is 
done to prevent front-end overload of base station receivers from mobile 
units operating in close promimtty. 




Mobile output power must be automatically reduced, if necessary, based, 
•on RSSI values from the current base station system channel, accordinq 
to the following table: 




■Average RSSI Range Maximum Operating Power Allowed 
Watts dB below 10 W 
RSSI < 24 10 o 
24< RSSI < 28 4 4 
28< RSSI < 32 1.6 8 
32<RSSI<36 0.63 12 
36< RSSI < 40 0.25 16 
40< RSSI 0.10 20 




Values given in the first column of the table must be stored in alterable 
non-volatile memory to allow for possible future adjustments. 
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With regard to automatic power reduction in mobile units, the maximum 
power output specified by the network on the TXPOW parameter sets an 
upper limit, but not a lower limit, on the actual output power to be used 
by the mobile unit 




The maximum effective radiated power (ERP) for a mobile must be limited 
to 10 watts. 




4.5.4 CARRIER ON STATE 






The controller shall key the carrier "on" (he. shall apply power to. carrier) 
only when it is ready to transmit a message. The transmitter, is ready 
under two different conditions. 




a) after switching from receiving to transmit condition, during which the 
switching time should be less than 20 ms (including CPU handling 
time) 




b) When switching from one channel frequency to another, during which 
the switching time should not exceed 30 ms. 




4.S.5 PROTECTION AGAINST FALSE TRANSMISSION 




A protection circuit shall be provided to minimize the likelihood that 
transmitter operation could occur falsely due to a component failure. The 
protection circuit shall consist of an RF output power detector and a 
transmitter enable which is entirely independent of the main transmitter orv 
•off control circuit The RF power detector and a transmitter enable which 
is entirely independent of the main transmitter on-off control circuit The 
RF power detector shall be examined from time to time by the control 
.logic and the radio should be shut down if RF power is detected when the 
radio is not keyed on. 




4.5.6 MOBITEX ACCESS NUMBER (MAN) 




The mobile access number will be included in the customer specific 
PROM, as documented elsewhere in this specification, it will be a 24 bit 
number that will be specific to the terminal, and will be programmed on 
at service initiation. 




4.5.7 STANDARD ELECTRO-MECHANICAL INTERFACES 




It is recommended that radio/modem equipment be designed with 
standard interfaces to facilitate customer connection of different terminals. 
If a manufacturer provides a totally integrated unit, this requirement does 
not apply. 
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The modem shall interconnect with the terminal via an RS-232 interface. 
If the application includes accessory peripherals (such as a printer), such 
connections shall also be by use of an RS-232 interface. 




4.6 TERMINAL TIMEOUTS AND PARAMETER STORAGE REQUIREMENTS 




The following timeout values will be in effect for terminal units operating 
Within the Cantel Mobitex network: 




4.6.1 POWER-ON DELAY 






Delay after power-on or return from 
45 15 seconds. 


"manual mode": 




4.6.2 QUICK SCAN DELAY 






Delay after lost contact with base, 
activated: 30 seconds. 


before the "quickscan" procedure is 




4.6.3 CONGEST TIME OUT 






Timeout on CONGEST state retrans 
120 seconds. 


mit: 




4.6.4 MAXIMUM REPETIONS 






Maximum number of transmit repetitions (default value of MAX_REP); 5 
•Note that the current value of MAX-REP is given by the network in the 
<SVP> frame. 




4.6.5 .PARAMETER STORAGE REQUiREfV 


ENTS FOR MOBILE UNITS 




4.6.5 PERMANENTLY STORED/UNALTERABLE 




• ESN 

• TTY = 3 






FBI = 4 

• Channel class = 4 

. Working method = 2 

• Radio Output power = 10 

• Radio Tx/Rx Switch Time = (< 20) 
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4.6.5.2 PERMANENTLY STORED/ELECTRONICALLY ALTERABLE BY 
AUTHORIZED PERSONNEL 




• MAN 

• Priority 

. Frame Synch Pattem(s) 

• Default List 

• Roam Scanning Cycle Length = 10 
. Congest Time Out = 120 

• Quick Scan Initial Delay = 30 sea 

• Power on Delay = 45 sec. 

. RSSI Levels for Power Control (=24, 28, 32. 36, 40) 




4.6.5.3 DYNAMICALLY ALTERABLE BY MOBILE 




« Group List 

• Temporary Default List 
. Current List. 

. Die/Live State 

• MAX-REP 

« Selected Frame Sync. Pattern 

• Personal Subscription List 

• Current Base Area ID 

• Current System Channel 

• Packet Sequence Number 
. Frame Sequence Number 

• Area ID's allowed 
.• • Present Text 






4.7 SCANNING PROCEDURES 






4.7.1 LISTS OF CHANNELS 






The mobile unit uses various lists of radio channels to search for new 
base radio stations during the roaming procedure. Refer to Chapter 2, 
Appendix A, for an overview of the roaming procedure. 




In order to facilitate the roaming procedure, the unit should have the 
ability to minimize the total number of radio channels that have to be 
searched. The following lists of channels are available in the mobile unit 
for scanning. 
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CURRENT-BASE is the base radio 
communicating at present, or the 


station with which the mobile unit is 
one with which it was last in contact. 




CURRENT-UST is received by the 
contains the system channels us 
stations. 


mobile unit in the <SVP> frame and 
ed by the neighbouring base radio 




DEFAULT-LIST is a list of all syste 


m channels used in the network. 




TEMPORARY DEFAULT-UST is 
channels in the mobile unit's usua 


an alternative, short list of system 
I (or authorized) operating area 




The choice of which of the two default lists normally used in the mobile 
unit will be dependent on bom the extent of the operating are and the 
particular application. However, the complete DEFAULT-UST defined by 
the network operator should be permanently stored in the mobile 
terminal, even though it may be seldom used 




-4.7.2 ALTERNATIVE PROCEDURES AND MODES 




In order to minimize the time during which mobile units are out of 
contact with a base station, the scanning procedure to be used will vary 
depending on particular circumstances. Specifically: 




1 . Base Stations in the area in which the mobile unit is operating may 
share an area system channel, or each of them may have its own 
separate system channel. 




2. The mobile unit may have contact with a base station, and therefore 
be using the normal scanning procedure; or it may have lost 
contact for some time, and therefore be using the quick scanning 
procedure. 




3. For roaming purposes, the system may be operating in FRAME 
Mode (in which case RSSI measurements are made using frame 
heads), or in CONTINUOUS MODE (in which case RSSI 
measurements are initially made on base station carriers that are 
maintained continuously on). 




Details of the normal and quick scanning procedures, and of the FRAME 
and CONTINUOUS modes of operation are summarized in Appendix A 
of Chapter 2. 
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With respect to case 1 above, the mobile unit must be designed to 
accommodate scanning of alternative base stations (normal scanning 
procedure), or searching for new base stations (quick scanning 
procedure) on the current (or last used) system channel frequency 
before scanning other channels. It is recommended that this be the first 
priority scanning operation in the mobile unit. 




Next, for either normal or quick scanning procedure, the mobile unit 
searches the current (neighbour) list of system channels provided by the 
network in the <SVP> frame, in the case of normal scanning, this 
search in conducted during the SCAN-Time interval designated In the 
<SVP> frame. 




Finally, for the quick scanning procedure (In case the mobile unit has not 
yet contacted a base station), either the normal or the temporary default 
list of system channels is scanned, depending on which has been 
designated for the mobile unit. During the quick scanning procedure, 
the unit .must return .to scan the last used system channel after every ten 
scans of other channels. 

The mode of operation in effect, FRAME or CONTINUOUS, does not alter 
the scanning sequence. CONTINUOUS mode cannot be used when 
base stations share an area system channel, but its use where possible 
will shorten the time required for a mobile unit to re-establish contact 
with the network after contact has been lost. 

While scanning under CONTINUOUS MODE, the mobile must, after 
finding a carrier with a satisfactory RSSI, acquire and evaluate one or 
more frame heads to determine whether or not it has found a valid base 
station. If it has not, scanning continues. 




4.7.3. PARAMETERS 






The maximum number. of channels to be stored in the current 
(neighbour) list of system channels in the mobile unit is 32. 




The maximum number of channels to be stored in the permanent default 
list of system channels in the mobile unit is 256. 




The maximum number of system channels to be stored in the alternative, 
temporary default list of system channels in the mobile unit is 64. 
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Which of the two default lists is to be used by the mobile unit during the 
quick scanning procedure must be selectable from the application layer. 

Further Information: R1-02 {appendix A), R1-08, R1-16, R1-18 

4.8. GENERAL DESIGN REQUIREMENTS 

4.8.1 COMMON REQUIREMENTS FOR ALL FIXED, MOBILE, AND PORTABLE 
TERMINALS. 

Dimensions: 

The manufacturer shall select dimensions of his product 
Weight: 

The manufacturer shall select the weight objectives for his product 
Radiation: 

Electromagnetic Interference (EMI) radiated from any terminal design 
must be within the limits specified by the Appropriate DOC regulations. 

Storage: 

When packaged, all terminals shall be capable of being stored in 
temperatures of -40 C. to + 65 C. and in humidities up to 90% for 
temperatures up to 30 C with constant air moisture content at 
temperatures between +30 C and + 65 C. 

4.8.2 ADDITIONAL REQUIREMENT FOR MOBILE TERMINALS. 
Radiation Limitations: 

Harmonic and Spurious Radiation, Carrier On: 
The mean power of harmonic and spurious emissions from the 
transmitter, as measured at the antenna connector with the transmitter 
properly terminated, shall be at least 25 microwatts. These emissions 
shall be measured as defined by Department of Communications 
publication RSS122 paragraph 7.3. 

Radiation with Carrier Off: 

With the transmitter keyed off, any emissions from the transceiver, as 
measured at the antenna connector with proper terminations, shall not 
exceed 60 dBm in the mobile transmit band, 896-901 MHz or -80 dBm 
in the mobile receive band 935 to 940 MHz. 
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Radiation susceptibility: 






The transceiver design and the specification for the associated RF cable 
connecting to the antenna shall provide sufficient shielding to permit 
normal operation of the mobile while thB internal combustion engine of 
the car or truck in which it is installed is operating at highway speeds. 




4.9 ENVIRONMENTAL REQUIREMENT 


3 




Mobitex terminals must meet the following basic requirements. Section 
4.9.1 below describes requirements for mobile units, designed for use In 
land vehicles and watercraft. Section 4.9 provides the requirements for 
fixed terminals. 




4.9.1 BASIC ENVIRONMENTAL REQUIREMENTS FOR VEHICULAR INSTALLED 
UNITS 




Temperature: 

The mobile unit must be" capable of operatioiyin'fhe temperature range 
of -25 C (13F) to + 55 C (131 F). The manufacturer may wish to meet 
additional extended temperature limits for applications in hot desert or 
in extreme winter environments. If so, he may specify the extended 
temperature limits his units are capable of meeting. 




Relative humidity: 

The terminal must be capable of operation at relative humidities between 
5% and 100% of temperatures below 30 C (86 F) and between 5% and 
. 90% at temperatures between 30 C. and 55 C. 




NOTE: 

Since relative humidity in a test chamber cannot be controlled with high 
accuracy, testing will be performed at humidities of 5% and 90%. While 
no attempt will be made to set the humidity above 90%, the manufacturer 
should recognize that at times during temperature cycling water in humid 
air will condense on the terminal and, unless hermetically sealed, on the 
circuit boards within the terminal.. The terminal must be capable of 
operation with water from humid air condensed on it and in it 




4.10 MASC INTERFACE ERROR MESS 
(to be supplied later) 


\GES 
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5. DOCUMENTATION AND REVISION CONTROL 

Each manufacturer shall maintain documentation of his terminal products 
and subassemblies. He must maintain records of revisions and waivers, 
if any, applicable to the equipment he produces, together with a record 
of the model designation, serial numbers, or production codes affected 
by any such revision or waiver. Where subassemblies or modules are 
procured from other vendors the manufacturer may either keep his own 
records applicable to the procured subassembly of module or require his 
vendor to do so. 

6. QUESTIONS AND ANSWERS 

From time to time, manufacturers will question Cantel concerning 
specification matters. All such questions will be answered by Cantel and 
the question and answer distributed to all registered holders of this 
. specification. Such questions and answers should be filed in this section 
of the specification. They will be numbered so that directions to destroy 
certain questions and ansyvers can be sent with updates to other section 
of the specification. 

6.1 Question: 

How does one know the length of an MPAK? That is, the MPAK doesn't 
have any field stating the length? 

Answer: 

Mobitex radio protocol. 

Here the frame length is stated in the primary block. In this block one 
. field states the number of blocks following the primary block. 

Line protocol 

As an example we use HDLC {and LAPB). 

In these protocols, the start and -the end of a frame is indicated by 
special flags (predefined bit combinations). If a receiver wants to know 
the length of a received frame, this is done by counting the number of 
bytes between the startand end flags. 
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APPENDIX A 



Frequency Ionization for Mobitex 



The minimum C/I requirement for the Cantel Mobitex network is 15 dB for a 1.2 
kbit/s data channel and 18 dB for an 8 kbil/s channel. Compared to the C/l 
requirement of 17 to 18 dB' for a voice channel which is generally applied to an 
800 MHz cellular system, It is possible that the frequency reuse pattern for the 
Mobitex network can be derived with reference to that of a cellular network. 

Most cellular systems have employed the standard AMPS channelling plan 
which permits the same group of radio frequencies to be reused in a specific 
pattern With the typical 7-site reuse patter (N = 7), it is generally possible to 
achieve a C/l protection ratio of 18 dB in an urban environment 

If we apply the N = 7 frequency reuse plan to the Mobitex system, it is 
-apparent that there" will be some excessive system margin during the initial 
implementation of our system operating at 1.2 kbit/s. However, since our 1.2 
kblt/s system wiH shortly be augmented by the 8 kbit/s system which requires 
more stringent C/l requirement, frequency planning for the Mobitex network 
should consider the worse case (Le., 8 kbit/s system). 

Since the C/l requirement for the Mobitex 8 kbit/s system is almost the same as 
that of a cellular system, Mobitex can virtually be regarded as a cellular system 
for frequency planning and coverage planning purposes. Taking account of the 
need to minimize the use of the radio spectrum and yet ensure adequate C/l 
protection to guard against co-channel interference, an N = 7 frequency reuse 
pattern is recommended 

The N = 7 frequency reuse pattern to be used for the Mobitex network is 
slightly different from that commonly seen In a cellular system, i.e. a 7/21 plan 
(7 cells/21 sectors). In the 7/21 plan, a minimum of three channels are required 
to be arranged in sectors within a cell. 

For the Mobitex network, omnidirectional antennas will be used at most of the 
base station sites and sectorized arrangements will be avoided as far as 
possible. This will help to minimize the requirement for spectrum allocation. 
There will be the cases where special engineering efforts (e.g., proper siting 
and positioning of the base station antenna) will be needed to meet the C/l 
requirement 

Based on an N = 7 frequency reuse pattern, the following frequency 
assignment plan for 12.5 KHz channelization of the 900 MHz trunking band is 
proposed: 
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GROUP BASE TX FREQUENCY 

1 F1 + 0.25N 

2 F1 + 0.25N + 0.025 

3 F1 + 0.25N + 0.050 

4 F1 + 0.25N + 0.075 

5 F1 + 0.25N + 0.100 

6 F1 + 0.25N + 0.125 

7 F1 + 0.25N + 0.150 



Where F1 Is the base Tx frequency (within the frequency range 935 MHz to 940 
MHz) for the common system channel and N = 1, 2, 3, etc. 

The corresponding base Rx frequency is 39 MHz below the Base Tx frequency 
p.e., Base Rx frequency - Base Tx frequency - 39 (MHz)]. 

This frequency plan is based on an equi-spaced channelling arrangement with 
,.,a minimum Tx/Tx separation of 250 KHz. It is necessary to maintain a minimum 
Tx/Tx separation of 250 KHz for satisfactory performance of the transmitter 
combiner. We consider this type of plan desirable to limit any possible 
intermodulation products to within the Mobitex system itself instead of causing 
potential problems to other radio systems, while at the same time reducing 
combining losses. 

Cantel has been assigned a national system channel; BASE Tx: 939.9875, 
Base Fbc 900.9875, and the following local channels: 

[939.9875,900.9875], [939.7500,900.7500], [939.7375,900.7375], 
[939.7250,900,7250], [939.5000,900.5000], [939.4875,900.4875], 
[939.4750,900.4750], [939.2500,900.2500], [939.2375,900.2375], 
9.2250,900.2250], [939.21 2S.900.21 25], [939.0000,900.0000], 
,9875], [938.9750,899.9750], [938.9625,899.9525], 

The frequency band 896-901/935-940 MHz (901-902/940-941 MHz is frozen) has 
400 channels (12.5 KHz channel width) available, in 10 blocks with block sharing 
between Canada and USA, and 40 channels per block. (Only the Base Rx band 
is shown) 



BLOCK 



40 CHANNEL BLOCK 
896.0 to 896.5 
896.5 to 897.0 
897.0 to 897.5 
897.5 to 898.0 
898.0 to 898.5 
898.5 to 899.0 
899.0 to 899.5 
899.5 to 900.0 
900.0 to 900.5 
900.5 to 901.0 
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Cantel Mobitex- 


MOBITEX 

Application layer for 
terminals 


- 


ABSTHACT 

This document specifies the application layer for 
terminals to be connected to the MOBITEX network. 
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1 INTRODUCTION 



1 . 1 GENERAL 

The application layer is the network's face to the users. 
This is where the user and the terminal designer have 
almost unlimited possibilities to adapt the terminals and 
use the network far many different applications. 

In this specification, all layers above the network layer 
are considered as the application layer. 

The application layer has been specified as little as 
possible. The minimum which has been decided upon is 
necessary for users to be able to quickly recognize and" 
use common functions in the different types of terminals. 

Most of the functions stated on the application level are 
only recommendations and can be used as required by the 
terminal manufacturer. 

Of course, the terminals should be easy to handle and 
should permit the communication which the user of the 
equipment may require. 

For the lowest of the application layers, the Transport 
Layer, separate recommendations are being considered. 
Among other things, these recommendations will deal with 
the handling of messages longer than 512 octettes 
(sequence numbering between terminals of sub-messages and 
the rearranging of received sub-messages into correct 
order before delivery to upper layers). 



Exhibit 2, p. 130 



Cantel Mobitex- 



2/1056 - A 296 5171/02 Oe 



1990-02-20 G 



2 FUNCTIONS IN THE APPLICATION LAYER 

The application layer is the user interface. The only 
functions where requirements and recommendations are 
specified are: 

- addressing of messages , 

- choice of status message, 

- emergency traffic, 

- personal subscription interface, 

- presentation of network messages, 

- manual radio mode, 

..- manual .activation of mobile, terminals., , 

- flow control, 

- network identification number, 

- area identification number and 

- radio channel lists. 

For other areas we recommend that terminal designers 
develop functions according to user requirements. 
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2.1 ADDRESSING OF MESSAGES 

A message contains the information which the user wishes 
to transfer, supplemented with information which is 
necessary for the message to reach the correct subscriber, 
in the network. 

There is a number of different methods of addressing a 
MOBITEX message between user and terminal. These methods 
can be divided up and designated in the following manner: 

* Number dialling: - MOBITEX subscription number 

(MAN) 

- abbreviated number 

- default number 

- number sequence 

- alternative dialling 

* Other addressing methods: 

- special keys 

- letter combinations 
(e.g names) 

- direct addressing with 

. MAN from connected application 
equipment . 

Each terminal which is connected to MOBITEX shall permit 
one or more of the methods above. The terminals which 
permit number dialling in any form shall also permit 
manual dialling with complete MOBITEX subscription numbers 
(MAN) . 

When presenting senders for messages received, MAN shall 
always be shown to the user. Either separate or parallel 
with one of the above address types. 
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2.1.1 GENERAL INFORMATION ABOtJT NUMBER DIALLING 

All number dialling is recommended to comply with the 
following principle: 

NO + FUNCTION + TERMINATOR 

NO is a number of one of the following types: 

- MAN 1-8 digits 

- abbreviated number a few digits, ended by numbering 

character #. 

- number sequence several optional numbers , 

separated by a comma ' , ' , 
asterisk '*' or semicolon ' ; ' 

- default number no number given - 

FDNCTION/TERMINATOR given 
directly. 

FUNCTION and TERMINATOR comprises of one or more 
predetermined key strokes. FUNCTION terminates the NO 
input and selects the function to be used (e.g. status 
message, text message or speech call). Additional 
information (e.g. status number or text message) is 
entered after FUNCTION and is terminated by TERMINATOR. 
TERMINATOR normally initiates the transmission (e.g. SEND 
button). For predetermined messages, FUNCTION and 
TERMINATOR can be combined in the same key. 

2.1.2 NUMBER DIALLING/PRESENTATION WITH MAN 

If a terminal allows any form of number dialling, the 
terminal shall also permit number dialling with MAN. 

MAN shall be stated and presented in decimal form. 

The sender's MAN shall be presented for each message to 
the user. This can be separately or in parallel with 
another address type. 
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2.1.3 NUMBER DIALLING WITH ABBREVIATED NUMBERS 
Recommendation : 

Terminals with number dialling can offer the user the 
option of using abbreviated numbers. Abbreviated numbers 
are defined locally in each terminal. 

An abbreviated number is distinguished by the terminating 
character ' #' . 

An abbreviated number is usually one or two digits. 

Abbreviated numbers are not supposed to start with one or 
more zeros. 



2.1.4 NUMBER DIALLING WITH DEFAULT NUMBERS 
Recommendation: 

A terminal can offer the user a very quick and simple 
addressing method - default numbers. 

When using default numbers, the terminal is designed so 
that it interprets the lack of address (NO) in the message 
as a certain predetermined address. 

The predetermined numbers can be either one default number 
per FUNCTION or a general default number for all 
FUNCTIONS . 
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2.1.5 NUMBER DIALLING WITH NUMBER SEQUENCE 
Recommendation.: 

Terminals which are connected to MOBITEX can permit 
addressing with number sequence. This means that the users 
can address one and- the same message to several 
independent addressees . 

When a number sequence is used, the terminal sends a 
message with an address list (refer to reference Rl-09). 

Note that the use of a number sequence when requesting a 
speech connection (connection request) is not permitted. 

All types of numbers which the terminal allows for 
separate number dialling shall also be permitted for 
number sequence. Conversion to MAN shall take place in the 
normal way. 

If another addressing principle is permitted, e.g. name, 
we recommend, that these addresses are also permitted in 
the number sequence. 

Addresses in the number sequence shall be separated by a 
comma ' , ' , asterisk or a semicolon' j ' . 

The number sequence is terminated by FUNCTION. 

Note that two separation characters in sequence shall be 
interpreted as the default number for the relevant 
FUNCTION - if default numbers are available. 



2.1.6 NUMBER DIALLING WITH OTHER NUMBERS 

Types of numbers other than those stated above may be 
used. Different types of internal company numbers belong 
to this category. 

These numbers must also follow the number dialling 
procedure . (NO + FUNCTION) and shall be converted to MAN in 
the application layer. 



2.1.7 OTHER ADDRESSING PRINCIPLES 

A number of methods for addressing messages between user 
and terminal may be used in addition to chose seated 
above. 
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2.1. a SPECIAL KEYS 
Recommendation: 

Terminals can be fitted with special keys each of which 
represent a MAN, or with keys which generate predetermined 
messages addressed with MAN, etc. 



2.1.9 LETTER COMBINATIONS 
Recommendation: 

The user can store MAN for a number of different users in 
the terminal and then select MAN for a message by writing 
the receiver 's. name with letters. 

2.1.10 DIRECT ADDRESSING FROM CONNECTED APPLICATION 
EQUIPMENT 

Recommendation: 

The addressing of messages can take place automatically in 
the application equipment if such equipment is connected 
to the terminal. 

We recommend that such addressing be carried out with MAN 
according to the format which is specified in relation to 
lower layers. If MAN is used, no further conversion is 
necessary. 
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2.2 STATUS MESSAGES 

Messages which are' often repeated such as "I'M AVAILABLE", 
"I'M ENGAGED", "I'M OFF TO LONCH" etc. can be coded as 
status codes. Such status codes constitute information in 
status messages. 

The advantage of a status message is that it is 
transmitted much quicker than .the corresponding text 
messages . 

The MOB I TEX network can transmit 256 different status 
codes in such status messages. Which status codes are to 
be used, and what they mean, are defined in each terminal. 

The status message type of traffic is recommended for all 
types of terminal which are connected to MOBITEX. 

2.2.1 CHOICE OF STATUS CODE 

The method of selecting a status code can vary somewhat 
between different .terminals. We recommend that one or more 
of the following methods be used from a terminal: 

' A) Direct dialling with special status keys, which 
generate addressed status messages with 
predetermined status code (normal address and status 
code generated by status key). 

B) Dialling with special status keys which generate 
predetermined status messages without addresses. 
Addressing is carried out according to the normal 
addressing method (NO + FUNCTION + TERMINATOR where 
FUNCTION + TERMINATOR are combined in the relevant 
status key) . 

C) Dialling with decimal (or possibly hexadecimal) 
status code and normal addressing. 



Initial zeros need not be entered before a decimal status 
code . 

The user's procedure when sending status messages shall be 
as near as possible to that used for other types of 
messages . 

Alternative A means a significant simplification of the 
procedure. 
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It is recommended that the terminal is able to present 
both the translated status code and the decimal scatus 
code (simultaneously or alternatively). This makes it 
possible to use one and the same terminal within different 
terminal groups with different definitions of status 
codes . 

For terminals which are used within several such groups, 
we recommend that a. further simplification of the 
procedure be made by the terminal converting the status 
code in accordance with different code keys depending on 
which sender the message has. 
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2.3 EMERGENCY TRAFFIC 

Emergency traffic normally means the following in terms of 
the user: 

- sending emergency signals from mobile terminals (mobile 
terminal subscription or personal subscription logged-in 
to mobile terminal), 

- receiving emergency messages in a fixed terminal, 

- sending an emergency acknowledgement from a fixed 
terminal and 

- setting up an emergency line connection between the 
receiving fixed terminal and the alarming mobile 
terminal. 

However, the network operator decides how the emergency 
service should be launched, i.e. which subscription types 
to generate and receive emergency messages. It could also 
be possible to manage this on an individual subscriber 
basis. 



2.3.1 EMERGENCY SIGNAL 

An emergency signal which is normally sent from a vehicle 
contains dynamic information. The form of this dynamic 
information component is defined in the network layer. 

The dynamic information contains current data about the 
user. This data may have been stored for a longer period 
in the mobile terminal, it. may have been accessed from 
peripheral equipment and/or may have been entered at the 
terminal short time before sending the emergency signal. 

The dynamic information may contain a maximum of 255 
alphanumeric characters from the ' MOBTTEX text code' (see 
reference Rl-06 for definition). The source of the 
emergency signal may also be indicated (see reference Rl- 
19 for definition). 

Each line of the dynamic information may normally contain 
a maximum of 80 characters. There must not be more than 10 
lines of dynamic information. 

The lines are separated from each other with a carriage 
return (CR) followed by a line feed character (LF). 
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2.3.2 EMERGENCY MESSAGES 

An emergency message which reaches an emergency receiver 
contains the dynamic information (i.e. the emergency 
signal) as well as the static information component which 
is stored in the network together with information about 
the addressee' of the emergency message. 

The static information contains general data about the 
sender, the terminal etc. which may be of interest in an 
emergency. The contents shall be compiled through 
collaboration between the sender and the addressee of the 
emergency message. 

The storage of static information for emergency messages 
is handled in .MOBITEX by network operators in accordance 
with the subscriber's wishes. The users are responsible 
for their emergency information being correct and current. 

The static component of the~^emergency information may 
normally contain a maximum of 256 characters -from the 
•MOBITEX text code* (see reference Rl-06 for def inicion) . 

The emergency message should not consist of more than 512 
characters. Each line in both the static and dynamic 
information components may contain a .maximum of 80 
characters. There must not be. more than 20 lines in both 
these components together. 

The lines are separated from each other by a carriage 
return (CR) followed by a line feed character (LF). 

The fixed terminals receiving the emergency message shall 
be able to print out the message. in plain text, according 
to 'MOBITEX text code' (see reference Rl-06 for defini- 
tion). 

When an emergency message is received at a terminal, the 
user is to be informed of this immediately. It is then 
optional whether the emergency message is to be presented 
directly in its entirety or whether the sender is to 
request the message manually. 
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2.3.3 EMERGENCY ACKNOWLEDGEMENT 

The emergency acknowledgement is sent from the receiving 
terminal to the sender of the emergency signal. 

The emergency acknowledgement is generated after having 
been initiated manually. 

The MOBITEX network does not carry out any monitoring or 
control that the emergency message is followed by an 
emergency acknowledgement. . 

The procedure for generating an emergency acknowledgement 
shall comprise a function selection followed by a suitable 
terminator . 

FUNCTION SELECTION + TERMINATOR 

Note-that this .procedure shall always be carried, out 
manually for security reasons. 

The emergency acknowledgement can be presented in a 
suitable manner in the alarming terminal. 



2.3.4 EMERGENCY CONNECTION 

A line connection for speech can be set up between che 
emergency receiving terminal and the alarming terminal (an 
emergency connection). 

Any automatic generation of an emergency connection in 
conjunction with an emergency acknowledgement can be 
solved in the respective application. The network 
interprets the emergency acknowledgement and the emergency 
connection as two separate procedures. 



2.3.5 EMERGENCY DISCONNECTION 

A mobile terminal involved in a one way emergency 
connection with the transmitter on, i.e. silent emergency 
connection , shall turn the transmitter off for five 
seconds each minute to be available for disconnection or 
other packets and to prevent the transceiver from being 
turned off after 10 minutes. The 10 minutes refers to the 
control circuit, which orohibits the continuous 
transmission of carrier for longer periods than 10 
minutes, see reference Rl-18. 
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2.4 PERSONAL SUBSCRIPTION INTERFACE 



2.4.1 PASSWORD 

When a personal subscription is requested to be logged-in, 
a password must be entered, for the network to accept the 
subscriber. The password also shows that the operator is 
authorized to use the personal subscription. 

Since the password constitutes the key to the personal 
subscription, it is in the user's interest to keep his 
password secret. 

A password can consists of up to 8 alphanumeric 
characters. The permitted characters in the network are: 
the upper case letters A-Z and numbers 0-9. It is 
recommended that terminals convert lower case letters (a- 
z) in passwords _to upper case. 

The form of the password between terminal and network is 
described in the network layer. 

(In addition to this type of password the terminal can of 
course have local passwords which are never sent to the 
network). 



2.4.2 LOGGING IN PERSONAL SUBSCRIPTIONS 

A personal subscription can be used, in traffic after the 
order for log-in is approved. After cancelling the log-in, 
the subscription is deactivated. 



2.4.3 LOG-IN PROCEDURE 

The procedure for logging in a personal subscription in 
respect of the user follows the procedure below: 

FUNCTION SELECTION + MAN + TERMINATOR + PASSWORD + 
TERMINATOR 

■MAN' in this context is the personal subscriber's MAN. 

It is recommended that the password cannot be read from 
the terminal to safeguard the user's interest. Asterisks 
or similar can be printed out instead. 
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2.4.4 LOG-OUT PROCEDURE 

The procedure of logging out a personal subscription is 
similar to the log-in procedure, exceot that the password 
is left out. 

FUNCTION SELECTION + MAN + TERMINATOR 

•MAN' in this context is the personal subscription's MAN. 

2.4.5 NETWORK ORDER TO LOG OUT A PERSONAL SUBSCRIPTION 

When a terminal logs out a personal subscription, ordered 
by the network, the user should be informed about this. 
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2.5 PRESENTATION OF NETWORK MESSAGES 

Messages, except user traffic sent from the network, can 
be network orders or information. It can also be a message 
earlier sent by the user and for any reason returned by 
the network. 

In reference Rl-06 national requirements, such as language 
and identification number, made on the presentation is 
defined. 

These messages should be presented with the information 
given in the traffic state, described in reference Rl-09. 

Please note the presentation when receiving messages or 
signals described below. 

Note: Incoming packets with traffic state CONGEST are 

allowed to be retransmitted, but not within a given 
timeout (reference Rl-06). 



2,5.1 NETWORK INFORMATION AND ORDER MESSAGES • 

DTESERV: LIVE/DIE. 

If a DIE is received, or the user tries to 
send user traffic when a DIE is received, 
this should be shown to the user. . 
It should also be shown to the user when 
the terminal has received a LIVE, and can 
resume sending of user traffic. 

Signal : SPEECH_QDEOE_INFO . 

This is a signal created by the link 
layer. The meaning of the signal is that 
no speech channel is immediately 
available, and the speech connection 
request is placed in a queue. The signal 
contains the speech queue number for the 
request. Both that the request is queued 
and the queue number, should be presented 
to the user. 

Signal BASE LOST. 

~ This is a signal created by the link 

layer. The meaning of the signal is to 
show to the user that contact with che 
base radio station is lost and no messages 
can be transmitted. 
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Signal BASE_CONTACT. 

This is a signal created by the link 
layer. The meaning of the signal is to 
show to the user that contact with the 
base radio station is established again, 



2.5.2 



RETURNED MESSAGES AS "NOT TRANSMITTED" 



A message indicated as a "not transmitted " message, i.e. 
there is no acknowledgement of .the message from the 
network, should be presented as described below and 
required in reference Rl-09. 

General: The message is presented as a "not 

transmitted" message. The meaning of "not 
transmitted" shall be apparent during the 
. presentation. 

PSOBCOM: As "General". 

PSOSCOM: As "General". 

The application decides if the message 
shall be presented or not, e.g. send the- 
message to the link layer again. 

CSUBCOM: As "General". 

The disconnection is presented as a 
reaction of the "not transmitted" message. 
A line connection request can have the 
indication "not transmitted" when the 
lower layer has received a "NAT-frame". 

DTESERV: LOGINREQ/LOGOOT : 

As "General". 

The personal subscription is to be 
considered as logged-out by the terminal. 



As "General". 



A232 51KM 



Exhibit 2, p. 145 



Cantel Mobitex- 



2/1056 - A 296 5171/02 Ue 



1990-02-20 G 



2.6 MANUAL RADIO MODE 

Mobile terminals may have the ability to switch over to 
manual radio mode, e.g. to be used in another network. 
Before leaving MOBITEX mode and entering manual mode the 
terminal shall transmit an INACTIVE packet. This is 
equivalent to the procedure at power .off described in 
reference Rl-09. Before che manual radio mode is entered, 
the INACTIVE packet should be acknowledged. The terminal 
should wait 15-20 seconds for the acknowledgement, before 
entering the manual radio mode. 

When the terminal leaves manual radio mode and returns to 
MOBITEX mode, an ACTIVE packet shall be transmitted 
according to the procedure at power on, described in 
reference Rl-09. 



Note: There are no other requirements made on "Manual 

radio mode" in the MOBITEX TERMINAL SPECIFICATION, 
.than the requirements made in this chapter. 
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2.7 MANUAL ACTIVATION OF MOBILE TERMINALS 

Mobile terminals may have the ability to transmit an 
ACTIVE packet, in order to activate themselves in the 
network. 

This could, for example, be used when the terminal has 
resumed contact with the network after having been out of 
radio coverage. The network may have inactivated the 
terminal during this time, because no. traffic have been 
possible to transfer to the specific terminal. 

Normally, an automatic activation is sent to the network 
after a certain delay-time, specified in reference Rl-06. 
This procedure could be replaced by a manual activation, 
if the activation delay is considered to be too long. 

This activation must be manual, i.e. by operator command. 

After power-off, an INACTIVE packet should be sent by the 
terminal. -Before the terminal is switched off, the 
INACTIVE packet should be acknowledged. The terminal 
should wait 15-20 seconds for the acknowledgement, before 
switching off. 
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2.8 FLOW CONTROL 

MOBITEX 13 a connection-less, packet-switched, type of 
network, that uses store-and-forward technique. Complete 
messages, small oc large, are transferred between end- 
users without establishing any connections. 

The end-users are connected to the network via different 
protocols and bit rates. In order to avoid congestion and 
buffering problems in the terminals of the end-users, it 
is recommended that the application layer of the terminals 
should include a protocol for data flow control. This 
could be compared to the xON/XOFF-handling of other 
asynchronous communications and would give a smoother 
control of the data flow than if it was included in the . 
protocol of lower layers. It will also alert the 
subscriber to what is happening. 
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2.9 NETWORK IDENTIFICATION NUMBER 

In order to make it possible for a mobile terminal to 
change between different networks, the terminals should 
have this ability. This will make it possible to: 

- have different MOB I TEX networks existing in the same 
area and in the same frequency band, 

- prevent mobile terminals from unnecessarily changing 
between networks. (no automatic, change of network). 

The network operator decides, in reference Rl-06, if 
terminals should have the ability to roam into and traffic 
t ff " e ? fc MOBITEX networks. If that is the case, there 
should be a possibility for the operator of the mobile 
terminal to manually change network, by selecting a new 
network identification number. 

The network identification number plan, i.e. the 
identification number of each network is defined in the 
document "Network Operator Information" [reference Rl-06). 

A network identification number can consist of up to 6 
digits. There are a number of different methods of 
selecting a new network, e.g. number dialling, special 
keys or letter combinations (network names). Please, see 
chapter "Addressing" in this document. v 

The selected network identification number should then be 
transferred to the physical layer, to be used in the 
.signalling with the network. 
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2.10 AREA IDENTIFICATION NUMBER 

Area identification numbers (area IDs) are used to specify 
geographical areas. Such an area is denoted as a traffic 
area and is given a unique area ID hy the network. 

A list of area IDs specify the area a mobile terminal may 
traffic. Outside the specified area, two possible cases 
exist: 

1) the terminal is not operational 

2) the terminal is operational, but may be debited a 
different fee. 

When a subscription is registered, the traffic area a 
mobile terminal may operate, is defined. These area IDs 
are registered in the network subscription record for each 
mobile terminal. Information about valid area IDs and 
whether the terminal should be operational or not outside 
the traffic area, is transferred to the mobile terminal in 
a packet via the radio path. 

If the terminal should not be operational outside the 
subscribed traffic area, it should be shown to the user 
that the mobile has left its traffic area and is not 
operational. As well, the user should.be told'when the 
mobile terminal is within its traffic area again. 

Should the terminal be operational, the user must still be 
notified that the mobile has left its traffic area and 
might be debited differently. The user should then be told 
when the mobile terminal is within its normal traffic area 
again. 
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2.11 RADIO CHANNEL LISTS 

The mobile terminals uses a list of radio channels, 
defined in document "Network operator information" 
(reference Rl-06, chapter "Scanning procedures"), to 
search for new base radio stations (roaming procedure). 

In order to speed up the roaming procedure , the terminal 
may have the possibility to shorten the channel list. This 
could be done from the application, either manually by the 
user or automatically (e.g. as in the second example 
below). This shortened list is called temporary default 
list, and is used by the link layer instead of the 
permanent default list. It should also be possible to ■ 
change or delete the temporary list from the application. 

For example, if the mobile terminal uses a very restricted 
traffic area, only those channels applicable to the 
present traffic area are-~r«§uired to be used by the 
roaming procedure. 

Another example is to let the information about which ' 
traffic area (area ID) the mobile terminal is within, 
control which channels to be used by the roaming 
algorithm. 
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3 INTERFACE WITH LOWER LAYERS 

Lower layers shall notify whether a message has not been 
transferred to the network. 

All addressing shall be converted to the MOB I TEX 
subscription number (MAN) in respect of a subordinate 
layer. 

For line connection handling, the signals HOOK-OFF and 
HOOK -ON shall be available to the network layer. These 
signals indicate whether and when the operator is ready to 
start and to finish a conversation. They are used to 
change the line-connection mode in lower layers. 



3.1 DATA MESSAGES WITH HIGHER PROTOCOL IDENTIFICATION 

A packet J?jLt.ype "HPDATA" in MOB I TEX network protocol ,• has 
a field for protocol identification number. This indicates 
the type of higher protocol used, i.e." a protocol above 
the network layer. 

The size of the protocol identification number in HPDATA 
is one octet. This octet shall be coded 

decimal value indication 

0 no protocol identification 

1-127 reserved for public protocols 

128-255 free to be defined for the subscriber 

application 

Public protocols means protocols that have been registered 
and assigned a protocol identification number by the 
network operator (reference Rl-06). 



Exhibit 2, p. 



Cantel Mobitex- 



2/1Q56 - A 296 5171/02 Pe 
1990-02-20 ' G I HIS 08. 2 



4 MOBITEX SUBSCRIPTION NUMBER (MAN) IN THE TERMINALS 

In MOBITEX each subscription and group is allocated a 
number of up to 8 digits (decimal). These allocations are 
called MOBITEX subscription numbers or 'MAN* and state the 
destination and origin of all traffic in MOBITEX. MAN 
shall always be stated when addressing between network and 
terminal. The designations which are used between user and 
terminal shall always be converted to MAN between terminal 
and network. 

Each terminal shall be capable of addressing messages to, 
as well as- receive messages from, all MANs in the decimal 
number series 0 - 16,777,215. 

The terminal shall allow messages to be received for 
subscriptions connected to the terminal as follows; 

MAN for the terminal's own subscription,. 

- 1 MAN for the All Terminals Group *), 

- 14 MANs for optional individual group subscriptions and 

- 7 MANs for personal subscription • 

all together 23 different MANs. 

*) All terminals in MOBITEX will belong to one common 
group, the All Terminals Group MAN, dedicated MAN 
number 7. This should be loaded into the terminal by 
the network in the group list, sent on the reception 
of BORN. 
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5 MOB I TEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 12, 13, 17, 20, 22, 24, 25 

Rl-09, 8, 17, 18, 19 

Rl-18, 14 

Rl-19, 12 



Below are the reference designations listed. 
Reference - Section 



Rl-01 

Rl-02 

Rl-03 

Rl-04 

R1-0S 

Rl-06 

Rl-08 

Rl-09 

Rl-11 

Rl-12 . 

Rl-16 

Rl-17 

Rl-18 

Rl-19 

Rl-20 



Arrangement of the documents 
MOBITEX System description 
General description of terminals 
Terminology 
References 

Network operator information 
Application layer 
Network layer 

Interface requirements, fixed' terminals 
Other requirements, fixed terminals 
Link layer, mobile terminals 
Physical layer, mobile terminals 
Radio equipment, mobile terminals 
Other interfaces, mobile terminals 
Other requirements, mobile terminals 
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ABSTRACT 

This document describes the network layer for terminals 
connected to the Mobitex system. 
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1 INTRODUCTION 

The specification of the network layer for the terminals 
connected to the HOB I TEX network comprises four documents. 
These documents are: 

Main document 

■Appendix A, Packet formats 
Appendix B, Dialogues 
Appendix C, Logical description 

The purpose of the different sections i of the documents is: 

Chapter 1 Is a brief introduction to the documents. 



Chapter 2 
Chapter 3 

Chapter 4 

Chapter 5 
Chapter 6 
Chapter 7 
Appendix A 

Appendix B 

Appendix C 



States the packet classes and the packet 
names which are relevant to the terminals. 

Defines the general structure of the 
relevant data packets. (Refer also to 
Appendix A) . 

Defines how data packets are used for . 
dialogue between terminal and network. 
(Refer also to Appendix B) . 

States the set of data packets, that is 
relevant for each type of terminal. 

Defines which parameters that should be 
stored at power off for a terminal. 

Defines which parameters that should be 
transferred to the data link layer. 

Together with Chapter 3 this provides an 
illustration of the individual data 
packet's structure. 

Together with Chapter 4 this provides an 
illustration of the dialogues between 
terminal and network. 

Shows the interaction between modules 
within the network layer, as well as 
between the network layer and the data 
link layer and the application layer. It 
also contains a logical description of the 
network layer. 
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1.1 THE NETWORK LAYER IN BRIEF 

Communication between 'the terminal and the MOB I TEX network 
has been divided into layers according to the model 
described in "General description of terminals". 

The network layer is the layer which is closest to the 
application layers. All communication through interfaces 
and external connections must be checked against the given 
set of rules for the network layer. All attempts to send 
something that does not comply with these rules should be 
prohibited. 



1.2 PROTOCOLS BETWEEN TERMINAL AND NETWORK IN BRIEF 

When a terminal user sends a MOBITEX message the terminal 
creates a data packet which it sends to the network. The 
data packet should contain the information which the user 
wishes to transfer, supplemented with information which is 
necessary for the message to reach the. correct subscriber 
in the network. 

Since data transmission is controlled by lower layers," 
traffic transmission in the network layer is carried out 
through negative acknowledgement . 

This means that the message is not normally acknowledged. 
The sendet is notified however if the message has not 
reached the addressee for any reason. In a situation like 
this, the message is returned to the sender with an 
indication of the cause of the fault. 

Messages to groups are excepted from the principle of 
•negative acknowledgement. It would be a very impractical 
procedure to use any type of acknowledgement for these 
messages since the groups can be of considerable sizes. 

All data packets to be switched between terminals and 
networks must follow the' structures and procedures stated 
in this specification. 
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2 PACKETS 

MOBITEX is a packet switching network which also allows 
ceal time connections between subscribers. 

There are two different types of traffic principles used 
in MOBITEX : 

- Packet switched traffic which is transmitted according 
to the 'store-and-forward principle. 

- Circuit switched traffic, used for real time connections 
between terminals. 



2.1 PACKET CLASSES AND PACKET NAMES 
2.1.1 Packet switched traffic 

In the packet switched, traffic in MOBITEX , data packets' 
are used to : 

- Transferring information from one subscriber to another 
subscriber. 



• Connecting a circuit switched^ connection between 
subscribers thus j 
or other informat: 



subscribers thus permitting the transmission of speech 
:ion, e.g. circuit switched data? 



- updating information which is stored in networks and 
terminals. 

2.1.2 Circuit switched traffic 

Circuit switched traffic, i.e. traffic which is exchanged 
over a real time connection is treated briefly in this 
document. . . 
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2.1.3 Packet classes 

Data packets in MOBITEX are divided into a number of 
packet classes. The four packet classes which are relevant 
to the terminal's communication with the MOBITEX network 
are: 

- Packet switched subscriber communication - PSCJBCOM 

- Packet switched emergency communication - PSOSCOM 

- Circuit switching for subscriber and - CSUBCOM 
emergency communication 

- Data terminal service communication 



PSOBCOM, PSOSCOM and CSUBCOM are in some parts of the 
specification called 'user traffic'. 



2.1.4 Transmission direction 

In the following sections the normal transmission 
direction(s) for each data packet is given. The direction 
is stated by: to/from terminal, to terminal or from 
terminal. • 

Note that a packet can also be sent in the opposite 
direction but this concerns a packet that can be not be 
transferred and is returned to the sender. 
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2.2 PACKET SWITCHED SOB 


SCRIBER COMMUNICATION 



Data packets which transfers information from one 
subscriber to another subscriber through the MOBITEX 
network are included in the packet-switched subscriber 
communication. 



Internal traffic; 

Packets which are included in this group are transferred 
between subscribers in MOBITEX. 



TEXT text messages to/from terminal 

DATA data messages to/from terminal 

STATUS status messages to/from terminal 

BPDATA data message with to/from, terminal 



- higher protocol 
identification 



External traffic : 

Packets included in this group are switched between a 
subscriber in an external telecommunication network 
connected to MOBITEX and a subscriber in MOBITEX who also 
subscribes to the relevant telecommunications network. 

EXTPAK messages from/to to/from terminal 

external networks 



A292315M 
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2.3 PACKET SWITCHED EMERGENCY' COMMUNICATION 

There are certain packets which are used for emergency 
traffic. 

Emergency traffic; 

Packets included in this group can be switched with high 
priority on the radio path between MOBITEX subscribers. 

SOS emergency signal . to/from terminal 

SOSINFO emergency messages to terminal 

SOSACK emergency acknowledgement to/from terminal 
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2.4 CIRCUIT SWITCHING FOR SUBSCRIPTION AND EMERGENCY 
COMMUNICATION 

Data packets ate included in circuit switching for 
subscription and emergency communication, in order to 
establish and disconnect a real time connection. 

The data packets in this class are used for communicatii 
between network and terminal. 



Circuit switched connections ; 

Packets which are included in this group are used for 
establishing circuit switched connections to be used for 
analogue signals such as speech or for real time data 
communication, e.g. normal modem. 



CONGRA 
LINSEL 



connection request 

connection request fast 

connection request granted 
line selected 



to/from 
terminal 



to/from 
terminal 



to terminal 



CONORD 
CONREA 



conn, order for group call 
ready for connection 



to terminal 



Emergency connections ; 

Packets in this group initiate priority emergency 
connections to terminals. These emergency connections 
permit speech or transfer of circuit connected data 
between MOB I TEX subscribers. 

Emergency connections are given priority over other 
circuit switched connections. 



emergency connection request 



emergency connection 
request fast 



to/from 
terminal. 



to/from 
terminal. 
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External connections : 

Packets in this group establish a real time connection 
between a connected telecommunications network and a 
terminal. These external connections permits speech or 
circuit connected data between a MOBITEX subscription and 
a subscriber in an external network, e.g. the public 
telephone network. 

EXTCONREQ external connection request to/from 



Connections with additional information : 

Packets in this group establish real time connections. The 
packet contains additional information which can be used 
for stating internal additional numbers (extensions) for 
other terminals. 

ADDCONREQ .... connection request with to/from 
additional information terminal 

ADDCONFAST connection request with to/from 

additional information fast terminal 

Disconnection : 

Packets in this group disconnect the real time connection 
to the terminal. 

DISCON disconnection of connection to/from 

terminal 

Line test : 

Packets in this group are used for test of a real time 
connection between the terminal and the network. 

CLOQPON circuit ioop test start to terminal 

CLOOPOFF circuit loop test end to terminal 

Line barring; 

Packets in this group are used to bar and open line, 
connections. 

LINEOFF line connection barring from 

terminal 

LINEON ' line connection opening from_ 
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2.5 DATA TERMINAL SERVICE COMMUNICATION 

The data terminal service communication includes data 
packets which transfer information between subscription/ 
terminal and network. 

The information transferred by these packets update the 
data in the terminal or network. This data is necessary 
for traffic switching in the network. 

Subscription state :. 

Packets in this group change the status of personal 
subscriptions -in the system. 



LOGINREQ 
LOGINGRA 
LOGINREF 
LOGOUT 
LOGOUTORD 
Terminal status : 

Packets in this group change the network's information 
about the status of the terminal. 



login request 
login request granted 
login request refused 
logout 

logout order 



from terminal 
to terminal 
to terminal 
from terminal 
to terminal 



ACTIVE 

INACTIVE 

DIE 

LIVE 

ROAMORD 
ROAM 

VICESOSRX 
SOSRX 



terminal active for 
the first time 

terminal active 

terminal not active 

terminal is not 
permitted to send user 
traffic 

terminal permitted to 
send user traffic again 

roaming order 

roaming message 

re-direction of 
emergency messages 

cancel emergency 
re-direction 



from terminal 

from terminal 
from terminal 
to terminal 

to terminal 

to terminal 
from terminal 
from terminal 

from -terminal 
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Terminal information: 








Packets in 
between the 


this group transfer terminal information 
terminal and the network. 




GROUPLIST 


list of group MAN 


to terminal 




FLEXREQ 


list of personal 
subscription MAN requested 


to terminal 




FLEXLIST 


list of personal 
subscription MAN 


to/from 
terminal 




INFOREQ 


terminal information 
requested 


to terminal 




INFO 


terminal 


information 


from 

• terminal _ 




TIME 


time information 


to terminal 




AREALIST 
ESNREQ 


list of valid area_IDs 

Electronic Serial Number 
requested 


to terminal, 
to terminal 




ESN INFO 


Electronic Serial Number 
information 


from- 
terminal 
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3 PACKET FORMATS 

The packets which are used in the Mobitex network layer 
are given the common designation MobitexPAcKet, or MPAK. 
MPAK is used in all communication between the 
subscriptions and the network. 



.An MPAK must never be more than 560 octets long. 



3.1 STRUCTURE OF MPAK 

This chapter describes the structure of that part of MPAK 
which is common to all types of packets sent to and from 
terminals. The part which can vary according to different 
types of packets is described later. 

The design of each individual packet that can be used with 
a terminal is described in APPENDIX A. 

Each MPAK is divided into different, parts according, to the 
following: 

- Common component which is included in all MPAK. 

- Addre ss list which is included in certain types of 
MPAK. The MPAK with the address list is formed by 
the terminal and sent to the network. The network 
copies the common component and type dependent 
component of such an MPAK, forms new MPAK and 
sends these to the addressees in the address list. 

- Type dependent component which is included in 
certain types of MPAK. The size and application 
depends on the packet concerned. 

The contents of the different fields in each component are 
described on the following pages. 
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3.1.1 MPAK without address list 
Common component of MPAK ; 

sender 



octet 1-3: 
octet 4-6: 



_J L_ 



addressee 



X 0 ,X X 



state reserve subscription 
flag flags 

"87654321 



X X XXX 



packet external packet 
class flag. type ' 



Any type-dependent part; 



octet 9 etc. 



(type-dependent) 



(X = optional 0 or 1) 
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3.1.2 MPAK with address list 
Common component of MPAK : 



octet 1-3: 
octet 4-6 : 

octet 7: 



addressee: MOBITEX network 
87654321 



X IX X 



state reserve subscription 
flag flags 
8 7 6 5 4 3 2 1 



X X X ,X X 



packet :. externals packet 
class flag type 



octet 9 : 

octet 10-12: 

octet 13-15: 

octet 16-18 : 

octet 19-21: 

octet 22-24: 

octet 25-27: 

octet 28-30: 



of addressees 



addressee 1 

addressee 2 

addressee 3 

. addressee 4 

addressee 5 

addressee 6 

addressee 7 



Any type-dependent component: 



octet 31 etc 
(X = optional 0 or 1) 



(type-dependent) 
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3.2 COMMON COMPONENT 






The common component of MPAK is included in all data 
packets which are used between terminal and network. 




3.2.1 Sender 






Senders 


(octet 1-3) 




The sender is the subscription or the network which 
originally generated the packet. 




The sender's MAN is given in binary code in 3 octets. 




The sender MAN can be a terminal subscription MAN, a 
personal subscription MAN or a network MAN. 




- 3.-2-2 - Addressee 






Addressee: 


(octet 4-6) 




The addressee is the subscription, group or network which 
was originally intended as the receiver - the original 
destination. 




The addressee's MAN is given in binary code in 3 octets. 




The addressee MAN can be a terminal subscription MAN, a 
personal subscription MAN, a group MAN or a network MAN. 




Note: The SENDER and ADDRESSEE fields always indicate the 
original sender and addressee, i.e. the content of 
the £ields are not swapped in returned messages. 









Exhibit 



2, p. 171 



CantelMobitex- 



5/1056 - A 296 5171/2 De 
199CH02-22 1'MTS09.2 



3.2.3 Traffic State 
Traffic state 



{octet 7, bit 6-8) 



The packet's traffic state is stated with 3 bits and can 
have the decimal values 0-7. 

A packet can have one of the following eight states: 

State =0 OK 

Meaning: 'OK' 

No problems have occurred during the 
switching. 

. Action: Present the message to the user (please 

refer to reference Rl-08). The traffic 
state need not be stated. 



Meaning: ' From mailbox' . 

This message is coming from the network 
mailbox. 

Action: This message is presented in the same way 

as other incoming messages (please refer 
to reference Rl-08). .It should also be 
presented to the user, at what time the 
message was placed in the mailbox. The 
meaning of the state should be apparent 
from the presentation. 

State = 2: IH_MAIL 

Meaning: 'Has been placed in the mailbox 1 . 

The addressee cannot be reached at the 
moment. This message has been placed in 
the network mailbox. 

Action: This returned message copy is presented in 

the same way as other incoming messages 
(please refer to reference Rl-08). In 
certain cases, the presentation of text 
and data in the type dependent component 
can be omitted. The meaning of the state 
should be apparent during the 
presentation. 
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State = 3: 
Meaning: 



State = 4: 
Meaning: 



State = 5 

Meaning: 

Action: 



'The addressee can not be reached' . This . 
message cannot be transferred or put in 
the network mailbox. 

This returned message is presented in the 
same way as other incoming messages 
(please refer to reference Rl-08). In 
certain cases, the presentation of text 
and data in the type-dependent component 
can be omitted. The meaning of the state 
should be apparent during the 
presentation. 

ILLEGAL 

The message could not be switched by the 
network. 

This returned message is presented in the 
same way as other incoming messages 
(please refer to reference Rl-08). In 
certain cases, the presentation of text 
and data in the type-dependent component 
can be omitted. The meaning of the state 
should be apparent during the 
presentation. . ' - 



Line or radio channels are congested. 

This returned message is presented in the 
same way as other incoming messages 
(please refer to reference Rl-08). In 
certain cases, the presentation of text 
and data in the type-dependent component 
can be omitted. The meaning of state 
should be apparent during the 
presentation. 
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State = 6: ERROR 



Meaning: 'Technical error'. 

The message cannot be transferred because 
of a technical error. 

Action: This returned message is presented in the 

same way as other incoming message (please 
refer to reference Rl-08). In certain 
cases, the presentation of text and data 
in the type-dependent component can be 
omitted. The meaning of the state should 
be apparent during the presentation. 



Meaning : 



Action..: ..JChAs. returned message is presented in the 

same way as other incoming messages 
(please refer to reference .Rl^-08) . In 
certain cases, the presentation of text 
and data in the type dependent component 
can be omitted. The meaning of the state 
should be apparent during the 
presentation. 

Note: As states 2, 3, 4, 5, 6 and 7 indicate returned 

messages but the SENDER and ADDRESSEE fields have 
not been swapped, the SENDER field should be used 
for match with the terminal's own MAN: s for these 
states (message returned to original sender). 
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3.2.4 Subscription Flags 
Subscription flags: 



[octet 7, bit 1-4) 



A subscript ion/ terminal can raise a number of flags in the 



i component of MPAK. A flag is raised when its 
contents will apply. Flags can be raised independently of 



each other. 



A flag is raised when its logic value is 1 and lowered 
when its logic value is 0. 



MAILBOX F 



[octet 7, bit 1) 



MAILB0X_F = 0 : Must not be placed in the network 
mailbox . 

MAILB0X_F = 1 : May be placed in the network 
mailbox. 



Flag 2: 



DIGITAL F 



[octet 7, bit 2) 



DIGITAL_F = 0 : Digital route not required. 
DIGITAL_F = 1 : Digital route required. 



Flag 3: 



SENDLIST F ■ 
SENDLIST F = 



(Octet 7, bit' 3) 



0 : Address list is not included. 

1 : Address list included. 



(octet 7 r bit 4 



UNKNOWN F = 0 : Normal position 
ONKNOWN~F = 1 : Subscription not here. 



Reserve flag: (octet 7, bit 5) 

This flag is reserved until further notice. 



\ial 51513 
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3.2.5 Packet class 






Packet class: 


(octet 8, bit 7-8 




This field states the class to which the packet belongs by 
2 bits in the common component of MPAK. The packet class 
can have the decimal values 0-3. 




The four classes are: 






Packet class = 0: 
Packet class =1: 
Packet class = 2: 
Packet class = 3: 


PSDBCOM 
PSOSCOM 
CSDBCOM 
DTESERV 




3.2.6 External Flag 






External flaqs: 


(octet 8, bit 6) 




The external flag is raised to indicate that the packet is 
being used in traffic with an external - network. 




This flag must be lowered to indicate internal traffic in 
MOBITEX. 




EXTERN F = 0 : 
EXTERN_F = 1 : 


Internal traffic 
External traffic 
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3.2.7 Packet Type 
Packet type; 



(octet 8, bit 1-5). 



Each packet name corresponds to a packet type together 
with a position on the EXTERN P flag. (Refer to 'Packet 
classes and packet name' for more details). 

Packet types are stated with 5 bits in this field. Packet 
types can have the decimal values 0-31. 

The following types of packets are used for terminals: 

Within packet class = Q, i.e. PSDBCOH: 

EXTERN_F=0: packet type=l: TEXT 

packet type=»2: DATA 

packet type=3: STATUS 

packet type=4: HPDATA 

£XT£RN_F=1: packet type«l: EXTPAK 

Within packet class ■ 1, i'.e. PSOSCOM: 
EXTERN F=0: 



EXTERN F=l: 



packet 


type*l: 


SOS 


packet 


type=2: 


SOSINFO 


packet 


type=3 : 


SOSACK 


class = 2, i.e. CSUBCQM: 


packet 


type=l : 


CONREQ 


packet 


type=2: 


ADDCONREQ 


packet 


type=3: 


CONGRA 


packet 


type=4 : 


CONORD 


packet 


type=5: 


CONREA 


packet 


type=6: 


DISCON 


packet 


type=7 : 


CLOOPON 


packet 


type=8 : 


CLOOPOFF 


packet 


type=9: 


LINEON 


packet 


type=10: 


LINEOFF 


packet 


type=ll : 


CONFAST 


packet 


type=12: 


ADDCONFAST 


packet 


type=13: 


LINSEL 


packet 


type=17 : 


SOSCONREQ 


packet 


type=27: 


SOSCONFAST 


packet 


type=2: 


EXTCONREQ 



Exhibit 



2, p. 177 



Cantel Mobitex- 



5/1055 - A 296 5171/2 Oe 



1990-02-22 A 



Within MPAK packet class = 3, i.e. DTESERV: 



packet 


type= 1: 


LOGIKREQ 


packet 


type=* 2: 


LOGINGRA 


packet 


type= 3: 


LOGINREF 


packet 


type= 4: 


LOGOOT 


packet 


type= 5: 


LOGOUTORD 


packet 


type= 6s 


BORN 


packet 


type= 7: 


ACTIVE 


packet 


type= 8: 


INACTIVE 


packet 


type= 9: 


DIE 


packet 


type=10 : 


LIVE 


packet 


type=ll: 


ROAMORD 


packet 


type=12 : 


ROAM 


packet 


type=13 : 


VICESOSRX 


packet 


type=14: 


SOSRX 


packet 


type=15s 


GROUPLIST 


packet 


type=16 : 


FLEXREQ 


packet 


type=17 s 


FLEXLIST 


packet 


type=18 : 


INFOREQ 


packet 


type=19 : 


INFO 


packet 


type=20: 


TIME 


packet 


type=21: 


AREALIST 


packet 


type=22: 


ESNREQ 


packet 


type=23: 


ESNINFO 



Packets not listed above are reserved. 
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3.3 ADDRESS LIST 

If an address list is included after the common component 
of the MPAK, this should be stated with a raised flag 
1 SENDLIST_F ' in the MPAK common component. 

An address list must always begin at octet 9 and end at 
octet 30. 

Note that the address list always has a length of 22 
octets, irrespective of how many addresses will be read by 
the network. 

The address list should be designed as shown in chapter 
'MPAK with address list'. 

The field 'number of addresses' states how many of the 
following 7 address fields that are valid. The MAN for the 
respective subscription should be stated in the 7 address 
fields. 

Empty address fields should be filled with zeros when 
creating the address list. 

A packet with address list is returned to the sending 
terminal if the packet type is not allowed or if an error 
occurs before the network has unpacked the address list. 



3.4 TYPE-DEPENDENT COMPONENT 

If an address list is included in MPAK, the type-dependent 
component begins with octet 31 otherwise it begins with 
octet 9 directly after the common component of MPAK . 

Further information on the type dependent fields is given 
for the respective packet in Appendix A. 
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4 PROTOCOL 

Some of the packets which the terminal sends to the 
network should be distributed to another subscriber. Other 
packets have the network as destination. 

Each terminal should be capable of storing a specified 
number of MOBITEX subscription numbers (MAN). These MAN 
are divided into MAN for terminal subscription, MAN for 
groups and MAN for personal subscriptions. 

Only packets which are sent to terminals and which have 
one of all the terminal's subscriptions as addressee or 
sender will be handled. These packets are the only ones 
which may be notified to the user. If any other packet 
reach the network layer, it should be sent back to the 
network with Subscription flag UNKNOWN F = 1. See chapter 
4.5.2 Flags. . 

All interchange of packets between terminal and network 
should be according to a protocol. This chapter describes 
the protocols for the dialogues which occur in the network 
layer between the. terminal and network in general terms. 

Appendix B describes each dialogue separately. The 
dialogues are divided into a number of groups which on the 
whole agree with the division of packets into packet 
classes. 

All packets which are referred to in this chapter are 
referred to in PACKET CLASS AND PACKET NAME and their 
structures are defined in PACKET FORMATS and APPENDIX A. 



4.1 TRAFFIC HANDLING PRINCIPLES 

Packets are normally not acknowledged on the network layer 
level. However, the sender is informed if a packet has not 
reached the addressee. In this case, the packet is 
returned to the sender with an indication of the cause of 
the fault. The fault is given in the traffic state field 
of the packet. 



Exhibit 2, p. 180 



'is** 



Cantel Mobitex- 


5/1056 - A 296 5171/2 Ue 


1990-02-22 A |MTS09.2 



4 . 2 ACTIVATION/INACTIVATION 

In order to avoid transmission attempts to terminals which 
cannot be reached, an activation/inactivation procedure is 
included in the terminals. 



Inactivation ; 

The terminal should inactivate itself by automatically 
transmitting an INACTIVE packet to the network 

1) before it is powered off. 

2) when the terminal's message buffer is full and 
the terminal is incapable of handling more packet 
from the network. 



A terminal may also be inactivated by the network. 

This occurs if -the network has repeatedly failed to reach 

the terminal with traffic. 



The terminal and its personal subscriptions are then 
regarded as inactive by the network until it receives an 
ACTIVE packet from the terminal. When a subscription is 
inactive, traffic to it is forwarded to the network 
mailbox or returned to the sender without attempt to reach 
the terminal. Messages are stored in the network mailbox 
according to the principle described in chapter 1 MOBITEX 
NETWORK MAILBOX ' in this document. 



If contact is lost during the attempts to transmit the 
INACTIVE packet no further attempts are made. If contact 
is already lost when INACTIVE should be sent, no 
transmission at all is attempted. 
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The terminal should activate itself by automatically 
transmitting an ACTIVE packet to the network: Y 

1) When it is switched on. 

2) When the terminal's message buffer has space for 
at least 6 messages of maximum length. 

3) When the data link layer in the mobile terminal 
indicates that the terminal should activate 
itself. This case arises when the data link layer 
has lost contact with the base radio station, and 
the contact is re-established with the same base 
station again. 

4) On order from the application layer. 

JJL^fiiSS P° s f ible to inse rt a delay time before sending 
the ACTIVE packet to the network. If user traffic from the 
terminal is generated during this delay period, the 
transmission of the ACTIVE packet could be omitted. 

Two different delays are defined : 

■ 1) Activation delay after power-on. 

2) Activation delay after lost contact with the 
network . 

PA^uireraenfca on these delays are specified in the Network 
operator information, please see Rl-06. 
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4.3 EMERGENCY TRAFFIC 

The handling of emergency traffic can be given priority in 
the network and should also be given priority in 
terminals. 

When an emergency message reaches a terminal, the user 
should immediately be given clear notice that the 
•emergency message has arrived. It may also be possible for 
the message to interrupt another activity so that it can 
be presented immediately in its entirety. 

When an emergency signal is initiated; the sending of the 
emergency signal from the terminal should be given 
priority over the sending of other messages. Assume that 
the user have ordered the terminal to send a text message. 
An emergency message is initiated by the user at the same 
time as the text message is to be transmitted. In this 
case the transmission of the text message should be 
interrupted, and the emergency message should be 
transferred. 



4.4 MOBITEX NETWORK MAILBOX 

Terminal and personal subscriptions can subscribe to the 
Mobitex network mailbox facility. 

If the addressee of a message can not be reached by the 
network, the message can be stored in the network mailbox. 
A message is stored in the network mailbox if : 

1) the sender of the message indicates so by using 
the subscription flag MAILBOX_F 

and 

2) the addressee subscribes to the mailbox service. 



If the message is stored "in the mailbox, a copy of the 
message will also be returned to the sender with traffic 
state IN_MAIL . 



When the subscription is activated or have finished a real 
time connection, the packets which have been placed in the 
mailbox are sent to the subscription. If the packet had 
traffic state OR when it arrived at the mailbox, the 
traffic state of the packet has changed to FROM_MAIL when 
it is. sent from the mailbox to the subscription? Packets 
with traffic states other than OK will pass the mailbox 
with an unchanged traffic state. 

Otherwise there is no change in the contents of the 
packet . 
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4.5 CIRCUIT SWITCHED CONNECTION 



A circuit switched .connection in MOBITEX is a real time 
connection which is primarily used for speech connections. 
A circuit switched connection may also be used for circuit 
switched data. 

Circuit switched connections are always bi-directional. 
The base stations operates in duplex. The mobile terminals 
operates in two-frequency simplex or duplex communication 
mode . 



There are two different methods of requesting a line 
connection, by using MPAK : 

1) CON**R (CONREQ, ADDCONREQ, SOSCONREQ, EXTCONREQ) 

or 

2) CON**F (CONFAST, ADDCONFAST, SOSCONFAST) 

If a line connection is initiated with a CON**R from" the 
A-party, the network requires that the B-party terminal 
informs the network when HOOK-OFF is done by sending a 
CONREA packet. If the line connection is initiated with a 
CON**F, no CONREA should be sent to the network. This 
means that the line connection is established when the B- 
party has successfully received the C0N**F packet. 
Please refer to Appendix A for description of packet 
formats and to Appendix B for line connection dialogues. 



Three different protocols are used for circuit switched 
connection : 



Prot 1: Is used in mobile terminals and fixed 
~ terminals with one line for' real time 
connection. 

Prot_2A: Is used in fixed terminals with several 
lines for real time connections. The 
network selects lines for real time 
connections. 

Prot_2B: Is used in fixed terminals with several 
lines for real time connections. The 
terminal selects lines for real time 
connections . 

For more information about differences between Prot 2A and 
Prot_2B see appendix A and appendix B. 
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4.6 THE USE OF FIELDS IN THE COMMON COMPONENT IN MPAK 

This section gives a guideline how the fields in the 
common component in MPAK are to be used. The structure of: 
the fields are defined in chapter ' PACKET FORMATS' in this 
document. 



4.6.1 Traffic states 

In a mobile communication network, certain situations can 
arise when the network cannot transfer the message. 

The traffic state field is used by the network to inform 
the terminal or subscription of the state of each 
individual packet. The reason for returning a packet to 
the terminal is stated in the traffic state field. 

Returned packets originating from an MPAK with address 
list can be returned without address list if the network 
has already formed the individual- messages , otherwise the 
original MPAK with address list is returned. 



- In each data packet only one traffic state can be 
indicated in the traffic state field. 

- The traffic state relates only to the packet in which it 
is stated. 

- A data packet will always have traffic state OK when it 
is generated by a terminal. 

- The terminal must never change the traffic state of a 
packet. 
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4.6.2 Flags 

The terminal should be capable of raising a number of 
flags in the common component of the MPAK. The terminal 
has no reason to read what are known as subscription flags 
for the incoming messages. External flags however are of 
interest to the terminal. 

• - Flags are raised independently of each other. 

- A flag is raised when its logic value is 1 and lowered 
when its logic value is 0. 



MAILBOX_F 

is used by the terminal, to indicate whether the 
network is allowed to store the packet in the 
network. mailbox if the packet cannot be forwarded to 
the addressee. MAILBOX_F can be raised by a terminal 
when ordered by the user, or by default. 

DIGITAL_F " — - - 

is used by the terminal to indicate that a digital 
route is required for the requested circuit switched 
connection. DIGITAL_F should not be used when 
requesting circuit switched connection to groups. 
digital_f can .be raised by the terminal when ordered 
by the user. 

MOTE : 

DIGITALJ? should always be set =0. 
SENDLIST_F 

indicates that the packet includes an address list. 
This means that the network will create a copy of 
MPAK common component and MPAK type-dependent 
component, addressed to each addressee in the 
address list when the packet enters the network. The 
network considers each copy as an independent packet 
generated by the sender. SENDLIST_F is raised by the 
terminal when the sender gives several addresses for 
a message. 
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If the addressee, (or the sender in case" of returned 
packets, traffic states- 2, 3, 4, 5, 6 and 7) is not 
in the terminal's list of subscriptions, the 
terminal raises this flag and returns the message to 
the sender. UNKNOWK_F is therefore raised for a very 
specific error situation. 

Exception: In case this error occurs for a CONREQ, 
ADDCONREQ, SOSCONREQ, EXTCOKREQ, CONFAST, ADDCONFAST 
or a SOSCONFAST packet it must not be returned to 
the network. Instead, a DISCON packet should be sent 
to the network with the UNKNOWN' F flag set. 



EXTERN_F 

Is raised to indicate that the packet refers to 
traffic with an external telecommunication network, 
connected to MOBITEX. 



RESERVJ? 

Should always be set = 0, until further notice. 



Exhibit 2, p. 



33 





Cantel Mobitex- 


nrrr 1 I 

5/1056 - A 296 5171/2 Ue 




T990-02-22 'a 1 MTS09.2 




4.6.3 When generating MPAK 




The fields in the common component of the MPAK will be 
used according to the following for all packets generated 
by the terminal. There are restrictions concerning the 
sender and addressee. These restrictions are described at 
the presentation of each individual packet in appendix A. 




Sender : 






The sender is the MAN which originally sent the message. 
The MAN may denote a terminal subscription or a personal 
subscription logged-in to the terminal. 




Addressee: 






The addressee. is the MAN of the originally intended final 
receiver of the packet. The MAN may. denote a terminal 
subscription, a personal subscription, a group, the 
MOB I TEX network or an external network. 




Traffic state: 






The traffic state is always = OK 




Flags; 






MAILBOX F: . 

-"optional for a number of packets (see Appendix A), 
- lowered for all other packets. 




DIGITAL F: 

optional for a number of packets (CONREQ, ADDCONREQ, 
SOSCONREQ, EXTCONREQ, CONFAST, ADDCONFAST and 
SOSCONFAST), lowered for other packets. 




NOTE : 

DIGITAL_F should always be = 0. 




SENDLIST F: 

- optional for TEXT, DATA, HPDATA and STATUS 

- lowered for other packets. 




UNKNOWN F: 

-"lowered when generating a packet. 

- raised if the addressee is an external network. 

- otherwise it is lowered. 
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4.6.4 When receiving MPAK 

Data packets. can be received. by terminal at one of the 
following occasions: 

1) Normal case : 

the packet is sent to the addressee, MAN match with 
ADDRESSEE field 

2) Returned packets from network : 

the packet is returned to the original sender, MAN 
match with SENDER field. (The packet was returned by 
the network since it could not be transferred to the 
addressee) 

3) Packets to unknown subscriber in terminal : 

the received packet is addressed to a subscriber that 
is unknown to the terminal. This may -occur if the 
packet was addressed to a personal subscription that 
has logged-out at the instant the packet was received. 



1) Normal case ; 

In the normal case the message is transferred from the 
sender to the addressee. In this case the MPAK common 
component is as follows : 



Sender ; 

The terminal subscription, personal subscription or 
network MAN which originally created the packet. 



Addressee; 

One of the possible MAN:s of the receiving terminal 
(terminal subscription, personal subscription or group). 



Traffic state: 

OK or FROM_MAIL . (The latter applies if the packet has 
been stored in the network mailbox). 



Flags: 

EXTERN F is raised if this is an external packet. 
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, 2) Returned packets from the network : 




In this case, the packet was originally generated from. one 
of the terminal's subscriptions but for some reason it has 
been returned by the network. The reason for the network 
to return the packet is stated in the traffic state field. 




Returned packets must not be sent back to the network, but 
• should be presented to the application layer. 




Sender : 






The original sender of the packet, which in this case is 
one of the subscriptions of the terminal (terminal or 
personal subscription) . 




This field should be used to find an address match with 
one of the subscriptions at the terminal.. 




Addressee: 






The originally intended receiver of the packet. Normally a 
subscription MAN, group MAN or network MAN different from 
the MAN: s of the terminal. It should not be used to find 
an address match. 




Traffic state: 






One of the following: 


IN MAIL 

NO TRANSFER 

ILLEGAL 

CONGEST 

ERROR 

BUSY 




Flags: 






When SENDLIST F is set, the returned packet contains an 
address list and must be treated accordingly. 




3) Packets to unknown subscriber in the terminal 




If the addressee matching procedure mentioned in case 1) 
and 2) above fails, the packet should be returned to the 
network with the UNKNOWN F flag raised. No other changes 
in the packet is allowed" Please refer to chapter 'When 
returning MPAK to the network' in this document. 
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• 4.6.5 When returning MPAK to .the network. 

When returning a MPAK to the network the following rules 
apply: 

Senders 
Unchanged. 

Addressee; 
Unchanged. 

Traffic state; 
Unchanged . 



The UNKNOWN_F flag should be raised by the terminal 
returning tEe packet. 

All other flags must be unchanged. 



Exception: In case a CONREQ, SOSCONREQ, ADDCONREQ, 
EXTCONHEQ, CONFAST, ADDCONFAST or a SOSCONFAST packet is 
received under the circumstances described here, it must 
not be returned. Instead, a DISCON packet should be sent 
to the network with the UNKNOWN F raised. 
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4.6.6 MPAK returned by the link layer. 

In this case the packet is returned by the link layer to 
the network layer. The reason for this could be that the 
link layer has lost contact with the network. It must be 
noted that the packet may have been successfully received 
by the network, but the acknowledgement from the network 
to the terminal has been lost. 



Sender: 

The original sender of .the packet. 
Addressee: 

The originally intended receiver of the packet. 

Traffic state : 
Not changed. 



Flags : 

No flags has been changed by the link layer. 



3i;<Cwrt 
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Returned packet from the link layer should be considered 
as 'not transmitted' and must be treated as follows: 



PSOBCOM: The message is indicated as a "not 

transmitted" message, and sent to the 
application layer. 

• PSOSCOM: The message is indicated as a "not 

transmitted" message, and sent to the 
application layer. 

CSUBCOM: The message is to be considered as a 

disconnection of the actual line 
connection. 

The message is indicated as a "not 
transmitted" message, and sent to the 
application layer. 

DTESERV : LOGINREQ/LOGOOT : 

The message is indicated as a "not 
transmitted" message, and sent to the 
application layer. 

DTESERV : ACT IVE/ INACTIVE : 

The message is indicated as a "not 
transmitted" message, and sent to the 
application layer. 

DTESERV: SOSRX/VICESSOSRX: 

The message is indicated as a "not 
transmitted" message, and sent to the 
application layer. 



4.6.7 MPAK returned by the network layer to the 
application layer 

When the network sends MPAK DIE the terminal is prevented 
from sending any user traffic. 

The network layer in terminal should notify the 
application layer when it receives a DIE packet. 
Packets sent from the application layer when the network 
layer is in the DIE state should be returned to the 
application layer. 

The DIE state is valid until the network layer in the 
terminal receives a LIVE packet from the network. The LIVE 
packet should also be presented to the application layer 
in order to indicate that user traffic is allowed to send. 
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4.7 MESSAGE BUFFERS IN TERMINALS 

The terminal must have a buffer for received, but unrea'd 
messages. This buffer must be able to store at least 6 
messages of maximum length. 

If the buffer becomes fuir, an INACTIVE packet should be 
sent to the network. Traffic to the terminal will then be 
directed to the network mailbox or returned to the sender. 

When the buffer is -full this should also be presented to 
the user. 

When there is space for at least 6 new messages, then an 
ACTIVE packet should be sent. Normal traffic between the 
terminal and the network is chen resumed. 



4.7.1 Emergency traffic-buffers 

Terminals should always have enough memory space both for 
generating and receiving emergency traffic. 



4.7.2 Sending traffic while buffer is full 

The application may send any user traffic (FSUBCOM) , while 
the buffer is full. The terminal should, however, send an 
INACTIVE packet immediately afterwards. 

But when an emergency packet is initiated, this emergency 
packet should be transmitted immediately without sending 
an INACTIVE afterwards. 



Exhibit 2, p. 194 



40 



Cantel Mobitex- 



5/1056 - A 296 5171/2 De 



1990-02-22 A 



4.8 ELECTRONIC SERIAL NUMBER (ESN) CHECK 



Electronic Serial Number (ESN) check will protect 
subscribers from unauthorized use of terminals. 



The following packets includes the ESN 



To request the ESN from the terminal two MPAK are 
included : 



.. ESNINFO 

Fixed terminals without the ESN check function should also 
use the- -BORN and -ACTIVE packets as defined in this 
specification. Please see Rl-06 for ESN requirements for 
fixed terminals. 

The definition of the ESN format in the packets are 
described in Rl-06. 
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5 RELEVANT PACKETS FOR FIXED AND MOBILE TERMINALS 

Each terminal type should be capable of receiving all 
packets without any malfunction. 



The absolute minimum required of a terminal to be approved 
far connection to.MOBITEX is that it is capable of 
handling the following packets in a correct manner: 

mobile terminal: fixed terminal: 

DTESERV.BORN DTESERV . BORN 



ACTIVE 


ACTIVE 


INACTIVE 


INACTIVE 


DIE 


DIE 


LIVE 


LIVE 


ROAMORD 


GROUP-LIST 


• ROAM 


• TIME 


GHOOPLIST 




INFOREQ 




INFO 




TIME 




AREALIST 





ESNREQ 
ESN INFO 



If personal subscriptions are permitted the following 
packets must also be handled : 

DTESERV. LOGINREQ 
LOGINGRA 
LOGINREF 
LOGOUT 
LOGOOTORD 
FLEXREQ 
FLEXLIST 



If emergency traffic is permitted the following packets 
must also be handled : 

PSOSCOM.SOS 

SOSINFO 

optional to emergency receivers: 

PSOSCOM.SOSACK 
■ DTESERV. VI CESOSRX 
SOSRX 
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If line connection is permitted the following packets must 


also be handled : 




CSUBCOM.CONREQ 




CONFAST 




SOSCONP.EQ 
SOSCONFAST 




ADDCONREQ 
ADDCONFAST 




EXTCONHEQ 




CONREA 




DISCON 
CONORD 




optional for fixed terminal 


CSOBCOM.CLOOPON 




CLOOPOFF 




•LINEON 




LINEOFF 




additional for fixed terminal according to PROT_2A 


CSUBCOM.CONGRA 




additional for fixed terminal according to PROTJ2B 


CSDBCOM TINSEL 




Handling of packets in the class PSDBCOM depends on the 


the application and are optional : 


PSDBCOM. TEXT 
DATA 




STATUS 




HPDATA 




EXTPAK 
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6 PARAMETERS TO BE STORED AT POWER OFF 

The following network layer parameters are to be stored 
also during power off in order to be available immediately 
at power on: 

- terminal subscription HAN and Electronic Serial Number 
(ESN) should be stored permanently in such a way that 
they are impossible to change by software or by 
unauthorized persons. 

- current status originating from the reception of DIE or 
LIVE packets, 

- list of current group MAN:s (GROOPLIST) , 

- list of personal subscriptions currently logged-in to 
the terminal (FLEXLIST). 

- list of area IDs (AREALIST) 



Note: At power up it is recommended that the. stored 

information in the network layer are controlled 
against a checksum. If the checksum is found to be 
incorrect a BORN packet should be sent to the 
network in order to update the information. 



7 PARAMETERS TO BE TRANSFERRED TO THE DATA LINK LAYER 

The following network layer parameters are to be 
transferred to the data link layer : 

- list of current group MAN: s (GROUPLIST), 

- list of area IDs (AREALIST) 
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8 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 27, 40 
Rl-08, 17, 18, 19 



Below are the reference designations listed. 

Reference Section 

Rl-01 - Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 • Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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Network layer for terminals 
Appendix A. PACKET FORMATS 



ABSTRACT 



This document describes the structures of all data packets 
which are used between . terminals and the MOBITEX network. 
The criteria for generating the packets and actions to be 
taken when receiving packets are also described for each 
individual data packet. Mobitex data packets are denoted 
MPAK (Mobitex Packets). 
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1 INTRODUCTION 



Fields that appear in the type dependent part of several 
packet types are defined in chapter 2 in this document. 

Chapter 3-6 gives a detailed description of each 

individual MPAK.in the PSUBCOM, PSOSCOM, 
CSUBCOM and DTESERV classes, respectively. 

Documents in this section: 

Main document contains a general description of the 
• packet structure and a detailed 
specification of the common part of the 
packets. 



Appendix A 



Appendix B provides an illustration of the dialogues 
between the terminal and the network where 
MPAK are used. 

Appendix C contains a description of the interaction 
between modules within the network layer, 
as well as the interaction between the 
network layer and the data link layer and 
application layer. It also contains a 
logical description of the network layer in 
the mobile terminal. 
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2 FIELDS COMMON TO SEVERAL TYPE DEPENDENT COMPONENTS 

The following fields appear in the type dependent 
components of several packet types. 

KAN: 3 Octets used as subscription number. 

The MAN is in the range of 0-16,777,215 
decimal, with restrictions according to 
the specification in reference Rl-06. 

MAN will always be binary coded as 24 
bits, grouped in 3 octets. 

Example : 

MAN 12345678 {decimal) is the same as 
BC614E hexadecimal. The binary code will 
- be: 



octet 1: 
octet 2: 
octet 3: 



7 6 5 4 3 2 1 



10 111 10 0 



0 1 1 0 0 0 0 1 



(Hex: BC) 
(Hex: 61) 



0 10 0 11 r 0 (Hex: 4E) 



number of MAN: 1 octet; 



connection l octet. 

identity: (0-255 decimal) 

Description: Selected by the A party for 
the connection. The connection identity is 
cyclically incremented by one from 1 to 
255. Connection identity 0 implies that 
the packet is relevant irrespective of 
current connection ID. Only fixed 
terminals with more than one line for line 
connections and the MOB I TEX network can 
generate packets with connection identity 
equal 0. Please refer to appendix B. 
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1 octet 

(0-255 decimal) 

Description; Used for line connection. 
Line number 0 is used by mobile terminals 
and fixed terminals with only one single 
line for line connection. For fixed 
terminals with more than one line for line 
. connections, the line number corresponding 
to each specific line must be defined at 
the installation of the terminal to the 
network. 



protocol 

identification 

number: i octet 

(0-255 decimal) 
. Selected by A-party. 

Description; This field indicates that an 
end- to-end protocol, i.e. a protocol 
above the network layer, between A-party 
and B-party is in use. 

0 decimal means no protocol identifi- 
cation. 

1-127 decimal means that a protocol is in 
use. The protocol identification' number is 
administered by the network operator. A 
terminal should not use protocol 
identification numbers between 1-127 
without having registered the number at 
the network operator. 

128-255 decimal as protocol 
identification number may be used by a 
terminal without restrictions. 
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The time field should be -cleared (0) when 
sending from a terminal.. The time is 
inserted when the packet enters the. the 
first node in the network. The time 
indication can be used by the receiving 
terminal when receiving the MPAK. 

The time in MOBITEX is given as 1 MOB I TEX 
minute' in 3 octets, indicating how many 
minutes have elapsed since 1985-01-01 
00:00 (MOBITEX Local Time). 



The following algorithm is used to calculate MOBITEX local 
time from the . ' MOBITEX minute': 

hour = ( MOBITEX_minute MOD 1440 ) DIV 60 

minute = { MOBITEX juimite MOD 1440 ) MOD 60 

MD = MOBITEXjninute DIV 1440 

MT= 

(4291-HO*(MD-(36525*((100MD+30690)DIV36525))DIV 100))DIV10 

year . = 1984 + ( 100*MD + 30690 ) DIV 36525 + MT DIV 429 

month = ( 100*MT ) DIV 3061 - 1 - 12* ( MT DIV 429 ) 

day = MT - ( ( (100 * MT) DIV 3061 ) * 3061 ) DIV 100 

In the expressions above, DIV stands for whole number 
division and MOD for the rest of the whole number division 
(7 DIV 3=2 and 7 MOD 3 = 1). 



Exhibit 2, p. 206 



Cantei Mobitex- 



51/1056 - A 296 5171/2 Ue 



Assume that time indication is 876241 decimal (0D5ED1 
hexadecimal). The field for time indication then looks as 
tollows: 



octet 1: 
octet 2: 
octet 3: 



8 7 6 5 4 3 2 1 
—I 1 i 1 1 l l 



00001101 



01011110 



1 1 0 1 0 0 0 1 



(Hex: 0D) 
(Hex: 5E) 
(Hex: Dl] 



values- e2ample ' the variab les will have the following 
hour = 12 
minute' =1 

MD = 608 
MT =307 
year = 1986 
month = 9 
day = 1 

Thus the time is 1986-09-01 12:01 
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This chapter describes all "packet switched subscriber 
communication" packets. 



3.1 TEXT (text message) without address list: 
Designated sender: 

Terminal subscription or personal subscription. 
Designated addressee: 

Terminal subscription, personal subscription or group. 

Raised flags: 
Optional: MAILBOXJ? 

Criteria for generating the packet: 

The user or the application has ordered sending of the 
text information. 

The network's normal action when receiving the packet 

The network dispatches the packet to the designated 
address. 

The terminal's normal action when receiving the packet 

The information in the packet is stored, processed and/or 
presented to the user of the addressed subscription, 
according to reference Rl-08. 

Length of the packet: 

The length can vary between 12 and 523 octets. 
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TEXT without address list as generated by a terminal 
MPAK-COMMON COMPONENT: 



octet 1-3: 
octet 4-6: 
octet 7: 



addressee 



0 0 0 X 



0 0 0 0 1 



TYPE DEPENDENT COMPONENT: 
_l 1_ 

octet 9-11: 



octet 12: etc 



text {max. 512 octets) 



(X = optional 0 or.. 1) 



1-512 octets. 

According to ' MOBITEX text code'' 
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1 (text i 



isage) with address list: 



Designated sender: , 

Terminal subscription or personal subscription. 
Designated addressee; 

The network is stated in the ordinary addressee field. 

The intended message receivers are stated in the address 
list. The address list contains a list of subscription 
numbers, each of which can designate a terminal 
• subscription, a personal subscription or a group. Compare 
with the ordinary addressee field in ' TEXT 1 without 
address list. • 

Raised flags; 

Requirement: SENDLIST F . 
Optional : MAILBOX_P 



Criteria for generating the packet; 

The user or the application has ordered sending of the 
text information to a number of designated addressees. 



The network's normal action when receiving the packet : 

The network will make up an MPAK without address list for 
each of the addressees in the address list, taking the 
type dependent component from the original packet and 
putting the addressees from the address list into the 
addressee field of the respective new packets. The new 
packets are then dispatched to the designated addressees. 

The terminal's normal action when receiving the packet: 

The terminal only receives this packet as a returned 
packet. 



Length of the packet 
. The length can vary between 34' and 545 octets. 
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TEXT with address list as generated by a terminal 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 
ADDRESS LIST: 



addressee: MOBITEX network 



0 1 0 X 



0 0 0 0 1 



I ■ 



_J — I — 1_ 



octet 9: 

octet 10-12: 

octet 13-15: 

octet 16-18: 

octet 19-21: 

octet 22-24: 

octet 25-27: 

octet 28-30: 
TYPE. DEPENDENT COMPONENT 

octet 31-33: 



number of addressees 



addressee 1 
addressee 2 



_i I i_ 



_J ! 1_ 



addressee 3 

addressee 4 

addressee 5 

addressee 6 

addressee 7 



octet 34 etc 
(X = optional 0 or 1) 



_] i_ 



text (max, 512 octets) 



1-512 octets. 

According to 'MOBITEX text code' 
Please refer to Rl-06 
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3.3 DATA (data messages) without address list: 
Designated sender: 

Terminal subscription or personal subscription. 
Designated addressee: 

Terminal subscription, personal subscription or group. 
Raised flags: 
Optional: MAILBOX_F 

Criteria for generating the packet: 

The user or the application has ordered sending of the 
data-information..., 

The network's normal action when receiving a packet: 

The network dispatches the- packet to the designated 
addressee. 

The terminal's normal action when receiving a packet: 

The information in the packet is stored, processed and/or 
presented to the user of the addressed subscription, 
according to reference Rl-08. 

Length of the packet: 

The length can vary between 12 and 523 octets. 
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DATA without address list as generated by a terminal 
MPAK COMMON COMPONENT: 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8: 



sender 
addressee 



0 0 0 X 



0 0 0 1 0 



octet 9-11: 
octet 12:etc 



data {max. 512 octets) 



(X = optional 0 or 1) 



1-512 complete octets. 
Optional coding. 
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3.4 DATA (data messages) with address list.; 



Designated sender: . 

Terminal subscription or personal subscription. 



" Designated addressee: 

The network is stated in the. ordinary address field. 

The intended message receivers are stated in the address 
list. The address list contains subscription numbers, each 
of which can designate a terminal subscription, a personal 
subscription or a group. Compare with the ordinary address 
field in 'DATA' without address list. 



Raised flags: 

Requirement: SENDLIST_F 
Optional: MAILBOX_P 



Criteria for generating the packeti 

The user or the application has ordered sending of the 
data information to a number of designated addressees. 



The network's normal action when receiving the packet: 

The network copies the common component and type dependent 
component and dispatches the new packets to ' the designated 
addressees . 



The terminal's normal action when receiving the packet: 

The terminal only receives this packet as a returned 
packet . 

Length of the packet 

The length can vary between 34 and 545 octets. 
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DATA with address list as generated by a terminal 
MPAK COMMON COMPONENT: 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 
ADDRESS LIST: 
octet 9: 

octet 10-12: 

octet 13-15: 

octet 16-18: 

octet 19-21: 

octet 22-24: 

octet 25-27: 

octet 28-30: 
TYPE DEPENDEN 

octet 31-33: 

octet 34 etc 
(X = optional 0 or 1) 



addressee: MOBITEX network 



o 1 0 x 



o o o l o 



number of addresses 



addressee 1 



addressee 2 



addressee 3- 
addressee 4 
addressee 5 



addressee 6 



addressee 7 



data (max. 512 octets) 



1-512 complete octets. 
Optional coding. 
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3.5 STATUS (status messages) without address list; 
Designated sender: . 

Terminal subscription or personal subscription. 
Designated addressee: 

Terminal subscription, personal subscription or group. 
Raised flags: 
Optional: MAILBOX_F 

Criteria for generating the packet: 



The network's normal action when receiving the packet: 

The network dispatches the packet to the designated 
addressee. 

The terminal's normal action when receiving the packet: 

The information in the packet is stored, processed and/or 
presented to the user of the addressed subscription, 
according to reference Rl-08. 

Length of the packet 

12 octets. 
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STATUS without address list as generated by a terminal: 
MPAK COMMON COMPONENT: 



octet 1-3: 

octet 4-6: 

octet 7: 

octet a: 



sender 
addressee 



o-o o x 



0 0 0 1 1 



TYPE DEPENDENT COMPONENT: 
octet 9-11: 



(X ■ optional 0 or 1) 

status code: 1 octet. 

Optional coding. {0-255 decimal). 
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3.6 STATOS (status message) with address list; 
Designated sender: . 

Terminal subscription or personal. subscription. 
Designated addressee: 

The network is stated in the ordinary address field. 

The intended message receivers are stated in the address 
list. The address list contains subscription numbers, each 
of which can designate a terminal subscription ', a personal 
subscription or a group. Compare with the ordinary address 
field in 1 STATUS ' without address list. 



Raised flags: 

Requirement: SENDLIST P 
Optional: MAILBOX_P ~ 

Criteria for generating the packet: 

The user or the application has ordered sending' of the 
status information to a number of designated addressees. 

The network's normal action when receiving the packet: 

The network copies the common component and type dependent 
component and dispatches the new packets to the designated 
addresses. 



The terminal's normal action when receiving the packet: 

The terminal only receives this packet as a returned 
packet. 

Length of the packets: 
34 octets. 
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STATUS with address list as generated by a terminal 
MPAK COMMON COMPONENT: 
octet 1-3: 



sender 



octet 4-6: 

octet 7: 

octet 8: 
ADDRESS LIST: 

octet 9: 

octet 10-12: 

octet 13-15: 

octet 16-18: 

octet 19-21: 

octet 22-24: 

octet 25-27: 

octet 28-30: 
TYPE DEPENDEN 

octet 31-33: 

octet 34: 



— I 1 i_ _ 



addressee: MOBITEX network 



0 0 0 1 1 



— I— 



number of addresses 



addressee 1 
addressee . 2 
addressee -3 
addressee 4 
addressee 5 
addressee 6 
addressee 7 



status code 



(X = optional 0 or 1) 

status code: 1 octet. 

Optional coding. (0-255 decimal). 
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3.7 HPDATA (data message with higher protocol 
identif icacion] without address list 

Designated sender: 

Terminal subscription or personal subscription. 
Designated addressee: 

Terminal subscription, personal subscription or group. 

Raised flags: 
Optional: MAILBOX_F 

Criteria for generating the packet: 



The user or the application has ordered sending of the 
hpdata information.. 



The network's normal action when receiving the packet 

The network dispatches the packet to .the designated 
addressee. 



The terminal's normal action when receiving the packet: 

The information in the packet is stored, processed and/or 
presented to the user of the addressed subscription, 
according to reference Rl-08. 



Length of the packet: 

The length of the packet can vary between 13 to 524 
octets. 
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HPDATA without address list as generated by a terminal 
MPAK COMMON COMPONENT: 



_ _ —1 1— 



sender 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8: 

TYPE DEPEN 
octet 9-11: 

octet 12 : 

octet 13: etc 
(X = optional 0 or 1) 



0 0 0 X 



0 0 10 0 



protocol identification 



data (max 512 octets) 



1-512 complete octets. 
Optional coding. 
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3.8 HPDATA (data message with higher protocol 
identification) with address list 



Designated sender; ' 

Terminal subscription or personal subscription. 



Designated addressee: 

The network is stated in the ordinary, address field. 

The intended message receivers are stated in the address 
list. The address list contains subscription numbers, each 
of which can designate a terminal subscription, a personal 
subscription or a group. Compare with the ordinary address 
field in 'HPDATA' without address list. 



Raised flags; 

Requirement: SENDLIST F 
Optional: MAILBOX_P 



Criteria for generating the packet; 

The user or the application has ordered sending of the 
hpdata information to a number of designated addressees. 



The network's normal action when receiving the packet 

The network copies the common component and type dependent 
component, and dispatches the new packets to the 
designated addressees. 



The terminal's normal action when receiving the packet: 

The terminal only receives this packet as a returned 
packet. 



Length of the packet; 

The length of the packet can vary between 35 to 546 
octets. 
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HPDATA with address list as generated by a terminal 
MPAK COMMON COMPONENT: 



octet 1-3: 
octet 4-6: 
octet 7: 



sender 



_J !_ 



_i 1 L_ 



addressee: MOB! TEX network 



0 1 0 X 



octet 8: 0000010 
ADDRESS LIST: 



number of addresses 



addressee 1 



addressee 2 



addressee 3 



addressee 4 



octet 9: 

octet 10-12: 

octet 13-15: 

octet 16-18: 

octet 19-21: 

octet 22-24: 

octet 23-27: 

octet 28-30: 
TYPE DEPENDE1 

octet 31-33: 

octet 34: 

octet' 35 etc 
(X = optional 0 or 1) 

data 1-512 complete octets. Optional coding. 



addressee 6 



addressee 7 



' ' i I !_ 



protocol identification 



data (max 512 octets} 
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3.9 EXTPftK (external packet): 
Designated sender: 

External network, terminal subscription or personal 
subscription. 

Designated addressee: 



Raised flags: 
•Requirement: EXTERN_F 

Criteria for generating the packet: 

The user or the application has ordered sending of 
information to or from external telecommuncations network. 

The network's normal action when receiving the packet: 

If the network receives EXTPAK from a subscriber in 
HOBITEX, the packet is dispatched to the designated 
external telecommunications network which then sends it to 
the designated subscription in this network. 

If the network receives EXTPAK from an external 
telecommunications network, the packet is dispatched to 
the designated subscription in MOB I TEX . 

The terminal's normal action when receiving the packet: 

The information in the packet is stored, processed and/or 
e user of .the addressed subscription. 



presented to the i 
according to reference Rl-08. 



Length of the packet: 
To be defined. 
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EXTPAK as generated by a terminal 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8: 
TYPE DEPEN 

octet 9-11: 

octet 12 etc 



addressee: external network MAN 



0 0 0 0 1 



to be defined 



I 



to be defined 



(X = optional 0 or 1) 

The type dependent component has not yet been defined 
because the external gateways are not yet fully specified. 
The type dependent component will include a field 
"external data", transparent to data for the external 
network. 
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4 PSOSCOM 

This chapter describes all "packet switched emergency 
communication" packets. 




4-1 SOS (emergency signal): 




Designated sender: 






Terminal subscription or personal subscription 




Designated addressee: 






The network. 






Raised flaqs: . 






No raised flags. 






Criteria "for qeneratinq the packet: 




The user 'or the application has ordered sending of the 
emergency signal. 




The network's normal action when receiving the packet: 




The network generates SOSINFO and sends this SOSINFO to 
the emergency receiver. 




The terminal's normal action when receiving the packet: 




The terminal does not normally receive SOS. However, in 
the case of autonomous operation the SOS can be returned 
to all terminals within a limited area. In this case the 
SOS packet is addressed to the All Terminals Group MAN. 




The emergency information in the packet is stored, 
processed and presented to the user of the addressed 
subscription, according to reference Rl-08. 




Length of the packet: 






The length can vary between 11 and 267 octets. 
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SOS as generated by a terminal 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8: 



sender 



0 0 0 0 1 



addressee: M0B1TEX network 



octet 9-11: 
octet 12 etc 



dynamic emergency information 



dynamic 
emergency 

information: 0-256 complete octets. Selection of 

'MOBITEX text code' according to reference 
Rl-06. 
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4.2 SOSINFO (emergency message): 
Designated sender: . 

Terminal subscription or personal subscription can be 
designated the sender. 

The packet is always generated by the network however. 
Designated addressee; 

Terminal subscription or personal subscription. 

Raised flags: 
Mo raised flags. 

Criteria for generating the packet: 

The network has received SOS from the sender. The network 
supplements this with static emergency information stored 
in the network and creates a SOSINFO packet. The network 
send the SOSINFO to the addressee. 

The network's normal action when receiving the packet: 
The network does not normally receive SOSINFO. 

The terminal's normal action when receiving the packet: 

The information in the packet is stored, processed and/or 
presented to the user of the addressed subscription, 
according to reference Rl-08. 

Note that in the case of autonomous operation the SOSINFO 
can be returned to all terminals within a limited area. In 
this case the SOSINFO packet is addressed to the All 
Terminals group MAN. 

Length of the packet: 

The length can vary between 11 and 523 octets. 
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SOSINFO as generated by network 
MPAK COMMON COMPONENT: 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8: 



0 0 0 0 



0 0 0 1 0 



TYPE DEPENDENT COMPONENT i 
— I L_ 

octet 9-11: 



octet 12 etc 
octet etc. 



static emergency information 



dynamic emergency information 



static emergency information: 
0-255 complete octets. 

Selection of 1 MOB I TEX text code' according to 
reference Rl-06. 

dynamic emergency information: 

0-2S6 complete octets. 

Selection of 1 MOBITEX text code' according to 
reference Rl-06. 
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4.3 SOSACK (emerqency acknowledqement) : 


Designated sender: 




Terminal subscription or 


personal subscription. 


Designated addressee: 




Terminal subscription or personal subscription. 


Raised flags: 




No raised flags. 




Criteria for generating the packet: 


The terminal has ..received, a SOSINFO. Only a manual 
acknowledgement of SOSINFO will initiate SOSACK. (See 
reference Hl-08) . 


The network's normal action when receivinq the packet 


The network dispatches the packet to ..the designated 
addressee. Note that the network does not monitor that 
SOSINFO is followed by SOSACK. The use of SOSACK is 
optional to the application. 


The terminal's normal action when receivinq the packet: 


The information in the packet is stored, processed and/or 
presented to the user of the addressed subscription, 
according to reference Rl-08. 


The length of the packet: 




12 octets. 
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SOSACK as generated by a terminal 
MPAK COMMON COMPONENT: 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8:. 



sender 
addressee 



0 0 0 1 1 



octet 9-11: 
octet 12: 



emergency acknowledgement status | 



emergency acknowledgement status: 
1 octet. 

Optional coding (0-255 decimal) according to 
application. 
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5 CSDBCOM 






This chapter describes all "circuit switched subscriber 
and emergency communication" packets. 




5.1 CONREQ {connection 


request) : 




Designated sender: 






Terminal subscription or personal subscription. 




Designated addressee: 






Terminal subscription, personal subscription or group. 




Raised flags: 






Optional: DIGITAL_F 






Criteria for generating the packet: 




The user or the application has requested circuit switched 
connection. 




The network's normal action when receiving the packet: 




The network dispatches the packet to "the designated 
addressee and a real time connection is established. 




If the connection is approved and the terminal is prot_l 
or prot 2B, the connection is established without sending 
CONGRA. 




If the connection is approved and the terminal is prot_2A, 
a positive acknowledgement is sent in the form of CONGRA. 




The terminal's normal action when receivinq the packet 




The terminal normally receives CONREQ when another 
subscription has requested a connection with one of the 
terminal's subscriptions. 




Prot_l and prot_2A terminals will then generate CONREA for 
connection to take place. 




Prot_2B terminal will then generate LINSEL and CONREA for 
connection to take place. 




The terminal can also receive a returned CONREQ when the 
request has been refused for any reason.. The terminal then 
considers the connection as disconnected. 






Length of the packet: 
.10 octets. 
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CQNREQ as generated by a terminal 
MPAK COMMON COMPON ENT 

sender 



octet 1-3: 

octet 4-6: 

octet 7: 

octet B: 



octet 9: 
octet 10: 



connection identity 



(X - optional 0 or 1) 

Line_number when generating from a terminal 

prot_l and prot_2A: line number = 0 

prot_2B line number = actual line 

The connection identity is selected cyclically by the 
terminal . 
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5.2 CORF AST (connection request fast): 
Designated sender: 

Terminal subscription or personal subscription. 
Designated addressee: 

Terminal subscription, personal subscription or group. 
Raised flags: 
Optional: DIGITAL_P 

Criteria for generating the packet: 

The user or the application has requested fast circuit 
......switched connection. 

The network 'g normal action when receiving the packet: 

The network dispatches the packet to the designated 
addressee and a real time connection is established. 

If the connection is approved and the terminal is prot_l 

or prot_2B, the connection is established without sending 
CONGRA." 

If the connection is approved and the terminal is prot_2A, 

a positive acknowledgement is sent in the form of CONGRA. 

The terminal's normal action when receiving the packet 

The terminal normally receives CONFAST when another 
subscription has requested a fast connection with one of 
the terminal's subscriptions. 

For prot_l and prot_2A terminals the connection takes 
place immediately. 

prot_2B terminal will then generate LINSEL for connection 
to take place. 

The terminal can also receive a returned CONFAST when the 
request has been refused for any reason. The terminal then 
considers the connection as disconnected. 



Exhibit 2, p. 234 



Cantel Mobitex- 



51/1056 - A 296 5171/2 Oe 



CONFAST as generated by a terminal 
MPAK COMMON COMPONENT 



octet 1-3: 
octet 4-6: 
octet 7: 



0 0 0 



addressee 
_L — l — l— 



0 0X0 



I 



1 0 



octet 8 
TYPE DEPENDENT COMPONENT 
octet 9 



0 1 0 1 L 



octet 10: 



_i i i , i 



connection identity 



(X = optional 0 or 1) 

Line_number when generating from a terminal 
prot_l and prot_2A: line number = 0 
prot_2B line number = actual line 



The connection identity is selected cyclically by the 
terminal. 
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5.3 SOSCOKREQ (emergency connection request); 



Designated sender; 

Terminal subscription or personal subscription. 
Designated addressee : 

Terminal subscription or personal subscription. 



Raised flags; 
No raised flags. 



Criteria for generating the packet; 

The user or the application has requested emergency 
connection. 



The^network ' s normal action when receiving the packet; 

The network dispatches the packet to the designated 
addressee and a real time connection is established. 

If the emergency connection is approved and the terminal 
■is prot 1 or prot_2B, the connection is established 
without~sending CONGRA. 

If the emergency connection is approved and the terminal 
is prot 2A, a positive acknowledgement is sent in the form 
of CONGRA. 

The terminal's normal action when receiving the packet 

The terminal normally receives SOSCONREQ when another 
subscription has requested a emergency connection with one 
of the terminal's subscriptions. 

Prot 1 and prot 2A terminals will then generate CONREA for 
connection to take place. 

Prot_2B terminal will then generate LINSEL and CONREA for 
connection to take place. 

The terminal can also receive a returned SOSCONREQ when 
the request has been refused for any reason. The terminal 
then considers the connection as disconnected. 

Length of the packet; 
10 octets. 
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SOSCONREQ as generated by a terminal 
MPAK COMMON COMPONENT : 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8: 



addressee 



0 0 0 0 



0 1 0 0 0 1 



TYPE DEPENDENT COMPONENT: 
octet 9: 



line number 



octet 10: 



connection identity 



(X = optional 0 or 1) 

Line_nuraber when generating from a terminal 
prot_l and prot_2A: line number' - 0 
prot_2B line number = actual line 



The connection identity is selected cyclically by the 
terminal. 
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(emergency connection request fast); 
Designated sender: 

Terminal subscription or personal subscription. 
Designated addressee : 

Terminal subscription or personal subscription. 

Raised flags: 
No raised flags. 

Criteria for generating the packet: 



The network's normal action when receiving the packet: 

The network dispatches the packet to the designated 
addressee and a real time connection is established. 

If the emergency connection is approved and the terminal 
is prot_l or prot_2B r the connection is established 
without~sending CONGRA. 

If the emergency connection is approved and the terminal 
is prot 2A, a positive acknowledgement is sent in the form 
of CONGRA. 

The terminal's normal action when receiving the packet 

The terminal normally receives SOSCONFAST when another 
subscription has requested a fast emergency connection 
with one of the terminal's subscriptions. 

For prot_l and prot_2A terminals the connection takes 
place immediately. 

Prot_2B terminal will then generate L INS EL for connection 
to take place. 

The terminal can also receive a returned SOSCONFAST when 
the request has been refused for any reason. The terminal 
then considers the connection as disconnected. 

Length of the packet: 
10 octets. 
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SOSCONFAST as generated by a terminal 
MPAK COMMON COMPONENT: 



octet 1-3 : 

octet 4-6: 

octet 7: 

octet 8: 



sender 

addressee 
_j — i — 1_ 



0 0 0 0 



110 11 



octet 9: 
octet 10: 



line number 



connection identity 



(X = optional 0 or 1) 

Line_nuraber when generating from a terminal 
prot_l and prot_2A: line number" = 0 
prot_2B line number = actual line 



The connection identity is selected cyclically by the 
terminal. 
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5.5 ADDCONREQ (additional connection request): 



ADDCONREQ can be used to direct the connection to an 
extension connected to the receiving terminal, e.g. a PABX 
extension. In addition to the fields contained in CONREQ, 
ADDCONREQ has an additional field of 20 octets available 
to the application layers. This field. can be used to 
direct the receiving terminal to take the proper action. 



Designated sender: 

Terminal subscription or personal subscription. 



Designated addressee: 

Terminal subscription or personal subscription. 



Raised flags: 
Optional: DIGITAL_F 



Criteria for generating the packet: 

The user' or the application has requested additional 
connection. 



The network's normal action when receiving the packet: 

The network dispatches the packet to the designated 
addressee and a real time connection is established. 

If the connection is approved and the terminal is prptj. 
or prot 2B, the connection is established without sending 
CONGRA." 

If the connection is approved and the terminal is prot_2A, 
a positive acknowledgement is sent in the form of CONGRA. 
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The terminal's normal action when receiving the packet 

The terminal normally receives ADDCONREQ when another 
subscription has requested additional connection with one 
of the terminal's subscriptions. 

Prot_l and prot_2A terminals will then generate CONREA for 
connection to take place. 

Prot_2B terminal will then generate LINSEL and CONREA for 
connection to take place. 

The terminal can also receive a returned ADDCONREQ when 
the request has been refused for any reason. The terminal 
then considers the connection as disconnected. 

The field for additional information can be used without 
any limitations by the user. 

Length of the packet: 

30 octets. - ' 
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ADDCONREQ as generated by a terminal 
MPAK COMMON COMPONENT: 



octet 1-3 : 

. octet 4-6: 

octet 7 : 

octet 8: 



addressee 
l i — 1_ 



0 O'O 1 0 



TYPE DEPENDENT COMPONENT 
octet 9: 



line number 



octet 10: 
octet 11-30: 



— I 1 1 1 — -L^_l L_ 



connection identity 



additional information 



(X = optional 0 or 1) 
additional 

information: 20 octets. 

Optional coding. 

Line_number when generating from a terminal 

prot_l and prot_2A: line number = 0 

prot_2B line number = actual line 



The connection identity is selected cyclically by the 
terminal. 
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5.6 ADDCOHFAST (additional connection request fast): 




ADDCONFAST can be used to direct the connection to an 
extension connected to the receiving terminal, e.g. a FABX 
extension. In addition to the fields contained in CONFAST, 
ADDCONFAST has an additional field of 20 octets available 
to the application layers. This field can be used to 
direct the receiving terminal to take the proper action. 




Designated sender: 






Terminal subscription or personal subscription. 




Designated addressee: 






Terminal subscription or personal subscription. 




Raised flaqs: 






Optional: DIGITAI,_F 






Criteria for generating the packet: 




The user or the application has requested fast additional 
connection. 




The network's normal action when receivinq the packet: 




The network dispatches the packet to the designated 
addressee and a real time connection is established. 




If - the connection is approved and the terminal is prot 1 
or prot 2B, the connection is established without sending 
CONGRA." 




If the connection is approved and the terminal is prot_2A, 
a positive acknowledgement is sent in the form of CONGRA. 














R.PTM 
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The terminal's normal action when receiving the packet 

The terminal normally receives ADDCONFAST when another 
subscription has requested a fast additional connection 
with one of the terminal's subscriptions. 

For prot_l and prot_2A terminals the connection takes 
place immediately. ~ 

Prot_2B terminal will then generate LINSEL for connection 
to take place. 

The terminal can also receive a returned ADDCOHFAST when 
the request has been refused for any reason. The terminal 
then considers the connection as disconnected. 

The field for additional information can be used free by 
the subscriber. 



Length of the packet: 
'"30 octets. 
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ADDCONFAST as generated by a. terminal 
MPAK COMMON COMPONENT: 

sender 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8 : 



addressee 



octet 9: 
octet 10; 
octet 11-30: 



connection identity 



additional information 



(X = optional 0 or 1) 
additional 

information: 20 octets. 

Optional coding. 

Line_nuraber when generating from a terminal 
prot_l and prot_2A: line number = 0 
peat 2B . line number = actual line 



The connection identity is selected cyclically by the 
terminal . 
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(line connection request approved); 



Designated sender: 

Terminal subscription, personal subscription, group or 
external network. 

The packet is always generated by the network. 



Designated addressee: 

Fixed terminal- subscription prot 2A or personal 
subscription logged-in to a fixed" terminal prot_2A. 



Raised flags: - 
No raised flags. 

Criteria for generating the packet: 

The network has received CONREQ, SOSCONREQ, EXTCONREQ, 
ADDCONREQ, CONFAST, SOSCONFAST or ADDCONFAST from a fixed 
terminal prot_2A and approved circuit switched connection 
from the terminal. 

The network's normal action when receiving the packet: 
The network does not normally receive the packet. 

The terminal's normal action when receiving the packet: 

The terminal connects the circuit switched connection to 
the designated line. 

Length of the packet: 

10 octets. 
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CONGRA as generated by the network: 
MPAK COMMON COMPONENT: 
octet 1-3: 



octet 4-6: 
octet 7: 
octet 8: 



_l 1— 



addressee 
I i — 1_ 



0 0 0 0 



TYPE DEPENDENT COMPONENT: 



line number 



octet 10: 



i i i 1 1_ 



connection identity 



Note: The- line number is stated by the network. The 

connection identity is the same as the connection 
identity for CONREQ, SOSCONREQ, EXTCONREQ, 
ADDCONREQ , CONFAST, SOSCONFAST .or ADDCONFAST. 
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5.8 LIHSEti (line selected); 



Designated sender: 

Fixed terminal subscription prot_2B or personal 
subscription logged-in to a fixed terminal prot_2B. 

Designated addressee: 

Terminal subscription, personal- subscription or external 
network. 



Raised flags: 
No raised flags. 



Criteria for generating the packet: 

"The fixed terminal prot_2B or personal subscription 
logged-in to a fixed, terminal prot_2B has received CONREQ-, 
SOSCONREQ, EXTCONREQ, ADDCONREQ, CONFAST, SOSCONFAST or 
ADDCONFAST. 

Note: If the connection sequence is started with CONREQ, 
ADDCONREQ, SOSCONREQ or EXTCONREQ both L INS EL and 
CONREA must be sent by prot_2B terminal. 



The network's normal action when receiving the packet: 

If the connection sequence is started with CONFAST, 
ADDCONFAST or SOSCONFAST the network connects the circuit 
switched connection to the designated line. 

If the connection sequence is started with CONREQ, 
ADDCONREQ, EXTCONREQ or SOSCONFAST the network expects the 
terminal to send CONREA after LINSEL. 

The terminal's normal action when receiving the packet: 
Terminal does not normally receive the packet. • 
Length of the packet: 
10 octets. 
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LINSEL as generated by terminal; 
MPAK COMMON COMPONENT: 



octet 1-3: 

' octet 4-6: 

octet 7: 

octet 8: 



0 0 0 0 



0 110 1 



octet 9 : 
octet 10: 



line number 



connection identity 



Note: Line number = selected line { The terminal 
selects line number ) 

The connection identity is the same as the 
connection identity for CONREQ, SOSCONREQ, 
EXTCONREQ, ADDCONREQ, CONFAST, SOSCONFAST or 
ADDCONFAST. 
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5.9 CONORD (line connection order during group call): 


Designated sender: 




Terminal subscription or personal subscription. 


The packet is always generated by the network. 


Designated addressee: 




Group, 




Raised flags: 




No raised flags. 




Criteria for qeneratinq the packet: 


Another subscription has 
with the addressee which 


requested real time connection 
comprises a group. 


The network's normal action when receiving the packet 


The network does not normally receive, the packet. 


The terminal's normal action when receivinq the packet: 


The terminal connects the designated line (without 
acknowledgement with a data packet), i.e. CONREA and 
DISCON packets should not be sent by terminals which 
receive CONORD. 


Note only mobile terminals receive CONORD. 


Length of the packet 




10 octets. 





Exhibit 2, p. 250 



Cantel Mobitex- 



1990-02-19 



CONORD as generated by the network; 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8: 



_ _l I !_ 



addressee 
J 1 i_ 



_! i i i_ 



0 0 10 0 



TYPE DEPENDENT COMPONENT: 
octet 9: 



connection identity 



Note: A group call can only be disconnected by the A 

party. This means, when a B party want to leave or 
disconnect a group call, the line should be ' 
considered as disconnected without sending DISCON. 
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5.10 CONREA (ready for line connection): 
Designated sender; 

Terminal subscription or personal subscription. 



• Designated addressee: 

Terminal subscription, personal subscription or 
external network. 



Raised flags: 
No raised flags. 

Criteria for generating the packet: 

The terminal has received CONREQ, ADDCONREQ, SOSCONREQ or 
EXTCONREQ- from another subscription and is ready to 
connect the circuit switched connection (HOOK-OFF signal 
has been received from application layer). CONREA should 
not be sent when the terminal receives CONORD, CONFAST, 
ADDCONFAST or SOSCONFAST. 

The network's normal action when receiving the packet 

The connection is considered established until DISCON is 
generated by one of the parties or the network. 

The terminal's normal action when receiving the packet: 
The terminal does not normally receive the packet. 

Length of the packet 
10 octets. 
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CONREA as generated by a terminal: 



octet 1-3: 
octet 4-6: 
octet 7: 



addressee 



0 0 0 0 



0 0 10 1 



TYPE D 


EPENDEN* 


! COMPONENT: 


octet 


9: 


line 


number 






1(1111! 


octet 


10: 


connection 


identity 



Note: For prot_l and prot_2A terminals the line number is 
the number that was entered in CONREQ (ADDCONHEQ, 
SOSCONREQ or EXTCONREQ) by the network. For prot_2B 
terminals the line number is the number that was" 
enterd in LINSEL by the terminal 
The connection identity is same as the CONREQ 
(ADDCONREQ, SOSCONREQ or EXTCONREQ) referred to. 
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5.11 DISCON (disconnection): 



Designated sender; 

Terminal subscription, personal subscription, the 
network or external network. 

Designated addressee: 

Terminal subscription, personal subscription, group or 
external network. 



Raised flags: 
No raised flags. 



Criteria for generating the packet: 

The sender, the application or the network wishes to break 
the real time connection. DISCON is used irrespective of 
the type of connection. 

Note: A connection established with CONORD, i.e. a group 
call, should not be disconnected by the'B-party 
terminal. The terminal consider thus the line 
disconnected without sending DISCON. 



The network's normal action when receiving the packet: 
Prepares the disconnection. 

The terminal's normal action when receiving the packet: 
Breaks the connection. 

If the designated connection is already broken, no action 
is taken. 



Length of the packet: 
10 octets. 
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DISCON as generated by a terminal or network.; 
MPAK COMMON COMPONENT: 
octet 1-3: 



sender 



octet 4-6: 
octet 7: 
octet 8: 



_ __L_ 



addressee 



0 0 110 



TYPE DEPENDENT COMPONENT 
octet 9: 



line number 



connection identity 



Note Line number: 

prot_l terminal line number = 0 

prot_2A or pro't_2B line number— actual line 

Also the connection identity is to be same as the 
connection identity for CONREQ ( ADDCONREQ , 
SOSCONREQ, EXTCONREQ, CONFAST, ADDCONFAST or 
SOSCONFAST) . 
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(external connection request): 



Designated gender: 

Terminal subscription, personal subscription or 
external network. 



Designated addressee: 

External network, terminal subscription, personal 
subscription. 

Raised flags: 
Optional: DIGITALJF 

.Criteria for generating the packet: 

The user or the application has requested external . 
connection. 

The network's normal action when receiving the packet.: 

The network dispatches the packet to the designated 
addressee and a real time connection with the external 
network is established. 

If the connection is approved and the terminal is prot_l 
or prot_2B, the connection is established without sending 
CONGRA. 

If the connection is approved and the terminal is prat_2A, 
a positive acknowledgement is sent in the form of CONGRA. 
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The terminal's normal action when receiving the packet: 

The terminal normally receives EXTCONREQ when another 
subscription has requested an external connection with one 
of the terminal's subscriptions. If the A party's 
subscription number in the external network is known, this 
is stated in the designated field in the type-dependent 
component . 

Prot_l and prot_2A terminals will then generate CONREA for 
connection to take place. 

Prot_2B terminal will then generate LINSEL and CONREA for 
connection to take place. 

The terminal can also receive a returned EXTCONREQ when 
the request has been refused for any reason. The terminal 
then considers the connection as disconnected. 



Length of the packet: 
30 octets. 
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EXTCONHEQ aa generated by a terminal 



octet 1-3: 
octet 4-6: 
octet 7 : 



_i I l_ _ - - - 

addressee 



ooooooxo 



0 0 0 1 0 



TYPE DEPENDENT- COMPONENT: 
octet 9 : 



line number 



octet 10: 
octet 11-30: 



connection identity . 



subscr. no. in external network 



(X = optional 0 or 1) 

Line_number when generating from a terminal 

prot_l and prot_2A: line number = 0 

prot_2B line number = actual line 

The connection identity is selected cyclically by the 
terminal . 

In cases where the packet is generated from the terminal, 
the addressee should be the external network's MAN. If the 
packet is received by a terminal, the sender is the 
external network's MAN, 

subscr. no. in external network: 

The subscription number in the external network of 
the intended addressee (i.e. the B-party). The field 
size is 20 octets and the number is given right 
■ justified (leading spaces) according, to 'MOB I TEX 
text code 1 . 
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Example: 












The telephone number 031- 
will be the following in 


90 300 is coded as 03190300 and 
1 MOBITEX text code" : 




8 7 


6 .5 


4 3 
J 1 1 


2 1 




octet 1: 


0 0 


1 0 


0 0 


0 0 


(space) 








octet 2: 


0 0 


1 0 


0 0 


0 0 


{ space ) 








octet 11: 


0 0 


1 0 


0 0 


0 0 


(space) 








octet 12: 


0 0 


1 0 


o °. 


0 0 


(space) 








octet 13: 


0 0 


1 1 


0 0 


0 0 


(0) 




1 




octet 14: 


0 0 


1 1 


0 0 


1 1 


(3) 




1 1 1 t 1 1 1 




octet 15: 


0 0 


1 1 


0 0 


0 1 


(1) 




1 1 1 1 1 1 1 




octet 16: 


0 0 


1 1 


1 0 


0 1 


(9) 








octet 17: 


0 0 


1 1 


0 0 


0 0 


(0) 








octet 18: 


0 0 


1 1 


0 0 


1 1 


(3) 








octet 19: 


0 0 


1. 1 


0 0 


0 0 


(°) 








octet 20: 


0 0 


1 1 


0 0 


0 0 


(0) 















.VJ31SIS3/3 
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5.13 CLOOPON (loop teat start): 


Designated sender: 




The network. 




Designated addressee: 




Fixed terminal subscription. 


Raised flags: . 




No raised flags. 




Criteria for generating the packet: 


The network wishes to loop test the designated line for 
real time connection." 


The network's normal action when receiving the packet 


The network does not normally receive the packet. 


The terminal's normal action when receiving the packet: 


The Tx and Rx wires, of the designated line, should be 
loop tested to be measured by the network. All other 
activity on the line is discontinued. 


Length of the packet: 




9 octets. 
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CLOOPON as generated by the network; 
MPAK COMMON COMPONENT: 



octet 1-3 : 

octet 4-6 j 

octet 7: 

octet 8: 



sender: the MOBITEX network 



0 0 111 



TYPE DEPENDENT COMPONENT: 
I 1 !_ 

octet 9: 



line number 
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5.14 CLOOPOPF {loop test 


end) : 


Designated sender: 




The network. 




Designated addressee: 




Fixed terminal subscription. 


Raised flags: 




No raised flags. 




Criteria for generating the packet: 


The loop test on the line 


ends . 


The network's normal action when receiving the packet 


The network does not normally receive the packet. 


The terminal's normal action when receiving the packet: 


The terminal should break the designated loop test. The 
line activity is continued. 


The length of the packet: 




9 octets. 





A -.3251513 
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CLOOPOFF as generated by the network : 
MPAK COMMON COMPONENT: 



octet 1-3: 
octet 4-6: 
octet 7: 



sender: the MOBITEX network 

addressee 

_J I I l 1 1 1 

0 0 0 0 0 0 0 



octet 8: 



0 10 0 0 



line number 
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5.15 LIKEOH (openinq of 


line connection) : 


Designated sender: 




Fixed terminal subscription prot_2A 


Designated addressee: 




The network. 




Raised flags: 




No raised flags. 




! Criteria for generating the packet: 


A fixed terminal wishes to open one of its lines intended 
for real time connection. 


The network's normal action when receiving the packet 


The network opens the indicated line. 


The terminal's normal action when receiving the oacket: 


The terminal does not normally receive the packet. 


Length of the packet: 




9 octets. 
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LINEON as generated by a terminal: 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8: 



sender: fixed terminal 



addressee: the MOB I TEX network 



0 10 0 1 



TYPE DEPENDENT- COMPONENT 
1 1 !_ 

octet 9: 



line number 
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5.16 LINEOFF (barring of line connection): 


Designated sender: 




Fixed terminal subscription prot_2A 


Designated addressee: 




The network. 




Raised flags: 




No raised flags. 




Criteria for generating the oacket: 


A fixed terminal wishes to bar one of its line intended 
for real time connection. 


The network's normal action when receiving the packet 


The network disables the 


indicated line. 


The terminal's normal action when receiving the packet: 


The terminal does not normally receive the packet. 


Length of the packet: 




? octets. 
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LINEOFF as generated by a terminal; 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8: 



sender: fixed terminal 



_i i — i— _ _ 



addressee: the MOBITEX network 



0 0 0 0 



0 10 10 



line number 
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6 DTESERV 




This chapter describes all Data Terminal Service 
communication packets. 


6.1 LOGINREQ (loqin request): 


Designated sender: 




Terminal subscription. 




Designated addressees 




The network. 




Raised flaqs:- 




No raised flags. 




Criteria for qeneratinq the packet: 


A user or the application wishes to log-in a personal 
subscription to the terminal. 


Note: LOGINREQ should only be sent if there is enough 

space for another subscriber in the FLEXLIST and/or 
the subscription is not already present. 


The network's normal action when receivinq the packet: 


The network checks that the log-in can take place. 


The terminal's normal action when receivinq. the packet: 


The terminal does not normally receive the packet. 
However, if this would occur, it should be shown to the 
user that the log-in request has faild. 


Length of the packet: 




19 octets. 





A-.aZ5lS3.-3 
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LOGINREQ as generated by a terminal: 
MPAK COMMON COMPONENT: 



sender 



addressee: the MOB I TEX network 



octet 1-3: 
octet 4-6: 
octet 7: 

octet 8: 

TYPE DEPENDENT COMPONENT : 

_J L_ _ _ _ 

octet 9-11: 
octet " 12-19: 
password: 



0 0 0 0 1 



persona l subscription MAN 

— 1 L_ _~ I I 

password 



8 octets. 

Selection of 'MOBITEX text code" according 
to reference Rl-06. Passwords shorter than 
8 characters are filled with leading • 
spaces. 

Example: The password FANTOM: 
7 6 5 4 3 2 1 



octet 1: 

octet 2: 

octet 3: 

octet 4: 

octet 5: 

octet 6: 

octet 7: 

octet 8: 



0 10 0 0 



01001101 



(space) 

(space) 

(F) 

(A) 

(N) 

(T) 

(0) 

(M) 
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6.2 LOGINGHA (login request granted): 


Designated sender: 




Network, 




" Designated addressee: 




Terminal subscription. 




Raised flaqs: 




No raised flags. 




Criteria for generating the packet: 


The network approves the previously requested log-in 
(LOGINREQ). 


The network's normal action when receiving the.oacket: 


The network does not normally receive the packet. 


The terminal's normal act 


ion when receiving the packet: 


The terminal stores the personal subscription MAN as one 
of the subscription numbers the terminal may/can receive 
packets to. When LOGINGRA is received, this should be sent 
to the application layer to be shown to the user. 


Note: If the personal subscription is already logged-in, 
no further actions ar.e taken. 


Lenqth of the packet: 




11 octets. 
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LOGINGRA as generated by the network r 

MPAK COMMON COMPONENT: 

-1 1 !_ _ _ _ _ 



octet 1-3: 

octet 4-6: 

octet 7 : 

octet 8: 



sender: the MOBITEX network 



addressee 
i i_ 



0 0 0 0 



0 0 0 1 0 



T?PE DEPENDENT COMPONENT: 

I _ 

octet 9-11: 



Personal subscription MAN 
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6.3 LOGINREP (login request refused]: 


Desiqnated sender: 




Network ■ 




Desiqnated addressee: 




Terminal subscription. 




Raised flaqs: 




No raised flags. 




Criteria for qeneratinq the packet: 


The network does not permit the requested log-in. 


The network's normal action when receiving the packet: 


The network does not normally receive the packet . " 


The terminal's normal action when receiving the packet: 


The terminal notifies the user or the application that the 
log-in request has been refused by the network. 


Lenqth of the packet: 




11 octets. 
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LOGINREF as generated by the network; 
MPAK COMMON COMPONENT: 
octet 1-3 : 



sender: the MOB ITEX network 



octet 4-6: 



octet 7: 



_l l_ _ _ 



addressee 



o .0 0 0 



b oo l l 



octet 9-11: 



Personal subscription MAN 
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6.4 LOGOUT (loqout): 




Designated sender: 




Personal subscription. 




Desiqnated addressee: 




The network. 




Raised flaqs: . 




No raised flags. 




Criteria for qeneratinq the packet: 


A personal subscription wished to log-out from the 
terminal. The terminal should only send the packet if the 
subscription is in the PLEXLIST containing the personal 
subscriptions. After generating the packet, the personal 
subscription is deleted from the FLEXLIST. 


The network's normal action when receiving the packet: 


The network deletes the log-in. The subscription is 'at 
rest' until further notice. 


The terminal's normal action when receiving the packet: 


The terminal does not normally receive the packet. 


Lenqth of the packet: 




11 octets. 
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LOGOUT as generated by a terminal 
MPAK COMMON COMPONENT: 
octet 1-3: 



J_ _ _ _ _ _J 1 1_ 

sender 



octet 4-6: 
octet 7: 
octet 8: 



_i i_ 



addressee: the MOBITEX network 
_l l 



0 0 10 0 



TYPE DEPENDENT COMPONENT: 
octet 9-11: 



MAN (terminal subscription) 



Exhibit 2, p. 275 



77 



CantelMobitex- 


51/1056 - A 296 5171/2 tie 


a i990"02-19 13 "a j MTS09A.2 


6.5 LOGOOTQHD < loqout" order ) : 


Desiqnated sender: 




The network 




Desiqnated addressee: 




Terminal subscription. 




Raised flaqs: 




Ho raised flags. 




Criteria for qeneratinq the packet: 


The personal subscription can only be loggedrin to one 
terminal at a time. When a new log-in takes place and an 
old log-in is active (no LOGOUT has been sent), the 
network sends the LOGOUTORD packet to the old terminal in 
order to log-out the personal subscription from that 
terminal. 


The network's normal action when receiving the packet: 


The network does not normally receive the packet. 


The terminal's normal action when receiving the packet: 


The terminal deletes 'the personal subscription from the 
list of logged-in subscriptions. It should also be shown 
to the user that the personal subscription has been 
logged-out. 


Lenqth of the packet: 




11 octets. 





A 2325151-3 
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LOGQOTORD as generated by the network; 
MPAK COMMON COMPONENT: 



octet 1-3: 

octet 4-6: 

octet 7: 

octet 8: 



sender: the MOBITEX network 



0 0 0 0 



0 0 10 1 



TYPE DEPENDENT COMPONENT ! 
octet 9-11: 



Personal subscription MAN 
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6.6 BORN (terminal active for first time): 

Designated sender: - 
Terminal subscription. 

Designated addressee: 
The network. 

Raised flags: 
No raised flags. 

Criteria for generating the packet: 

The terminal is active in MOB I TEX for the first time or 
the terminal has lost important parts of its stored 
information, please see Main document, chapter "Parameters 
to be stored at power of. 

If important parts, as stated above, is lost, BORN is 
replacing ROAM until a GROUPLIST is received. In this case 
the terminal should clear the list of personal 
subscriptions and the personal subscription must log-in 
again. 

The network's normal action when receiving the packet: 

The network sends the necessary information to the 
terminal (GROUPLIST). 

The network also checks the terminal's Electronic Serial 
Number (ESN] . 

The terminal's normal action when receiving the packet: 
The terminal does not normally receive the packet. 

Length of the packet: 
12 octets. 
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BORN as generated by the terminal: 

MPAK COMMON COMPONENT: 

1 l l_ _ _ _ . 

octet .1-3: sender 



octet 4-6: 
octet 7: 
octet 8: 



addresse e; the MOBITEX network 

_J I L 



0 0 0 0 



0 0 110 



TYPE DEPENDENT COMPONENT: 
" -J 1 L_ 



octet 9 -12: 



ESN 4 octets. 

This field states the electronic serial number. 

Fixed terminals without the ESN function should fill 
in the ESN field with zero's (0's). 

For the ESN specification, please refer to Rl-06. 
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6.7 ACTIVE (terminal active): 
Designated sender; 
Terminal subscription. 

Designated addressee; 
The network. 



Raised flags: 
No raised flags. 

Criteria for generating the packet; 
Mobile terminal : 

There are four different criteria for the network layer in 
the mobile terminal to send an ACTIVE packet : 

1) At power-on or returning from manual radio mode. 

2) The message buffer has space for at least 6 
messages of maximum length. 

3) Re-establishing contact with the network. 

4) On order from the application layer • 

The transmission of the ACTIVE packet may be delayed a 
certain period of time (see reference Rl-06). 



Fixed terminal : 

The fixed terminal sends the ACTIVE packet immediately 
after power-on or when the data link layer has restarted. 



The network's normal action when receiving the packet; 

The network updates the information about the terminal 
subscription. Messages stored in the mailbox, which are 
intended to the terminal and the subscriber, are sent to 
the subscribers. 
The network checks the ESN. 

The terminal's normal action when receiving the packet; 
The terminal does not normally receive the packet. 
Length of the packet; 
12 octets. 



.V292S15U 
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ACTIVE as generated by the terminal: 
MPAK COMMON COMPONENT: 



octet 1-3: 

octet 4-6 : 

octet 7: 

octet 8: 



addressee: the MOB r TEX network 



oooo 



0 0 111 



TYPE DEPENDENT COMPONENT: 

l_l 1 1 — _ 

octet 9-12: ESN 



Fixed terminals without the ESN' function should fill 
in the ESN field with zero's (0's). 

For the ESN specification, please refer to Rl-06. 
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6.8 INACTIVE (terminal 


no longer active) : 


Desiqnated sender: 




Terminal subscription. 




Desiqnated addressee: 




The network. 




Raised flaqs: 




No raised flags. 




Criteria for qeneratinq the packet: 


The user or -the application wishes to inactivate the 
terminal. INACTIVE is sent before the terminal is switched 
off and before the mobile terminal enters manual radio 
mode . 


INACTIVE is also sent when the message buffer becomes 
full. 


The network's normal acti 


on when receivinq the riacket: 


The network registers the terminal as inactive, and will 
not send any message to the terminal until it is activated 
again. 


The terminal's normal action when receiving the packet: 


The terminal does not normally receive the packet. 


Lenqth of the packet: 




8 octets. 





Exhibit 2, p. 282 



Cantel Mobrtex- 



51/1056 - A 296 5171/2 De 



INACTIVE as generated by the terminal: 



octet 1-3: 

octet 4-6: 

octet 7 : 

octet 8: 



address ee: the MOBITEX network. 
_i I L_ 



0 0 0 0 



0 10 0 0 



TYPE DEPENDENT COMPONENT does not exist. 
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6.9 DIE (the terminal may not send. packets) : 


Designated sender: 




The network.. 




• Desiqnated addressee: 




Terminal subscription. 




Raised flags: 




No raised flags. 




Criteria for qeneratinq the packet: 


The network generates this packet in order .to prevent a 
terminal from send any user traffic to the network. 


The network's normal action when receiving a packet: 


The network does not norm 


ally receive the packet. • 


The terminal's normal action when receiving the packet: 


After the reception of DIE, the terminal must not send any 
user traffic {PSDBCOM, CSUBCOM, PSOSCOM) . Only DTESERV 
packets are permitted until a LIVE packet has been 
received. It should also be shown to the user, that the 
terminal has received a DIE, and cannot send any user 
traffic. 


Exceptions : 

1) A CSUBCOM 'speech request' received by the terminal 
should result in a DISCON sent to the network. 


2) The terminal may return packets to the network with 
the UNKNOWN_F raised. 


Length of the packet: 
8 octets. 
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DIE as generated by the network 
MP AK -COMMON COMPONENT: 
octet 1-3: 



octet 4-6: 
octet 7: 
octet 8: 



sender: the MOBITEX . network 

addressee _ . 

i I ■■ I — i 1 — i — 

I 0 0 0 0 0 0 

.0 0 1 0 0 1 



TYPE DEPENDENT COMPONENT does not exist. 
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6.10 LIVE (the terminal may send packets again): 


Desiqnated sender: 




The network. 




Designated addressee: 




Terminal subscription. 




Raised flags: 




No raised flags. 




Criteria for generating the packet: 


The terminal _has previously received 'DIE' but is now 
permitted to send user traffic again. 


The network's normal action when receiving the packet: 


The network does not normally receive the packet. 


The terminal's normal action when receiving the packet: 


The terminal may resume sending user traffic again. 
- It should also be shown to the user, that the terminal has 
received a LIVE, and can resume sending user traffic. 


Length of the packet: 




8 octets. 
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LIVE as generated by the network 
MPAK-COMMON COMPONENT: 
octet 1-3: 



.octet 4-5: 
octet 7: 
octet 8: 



sender: the MOBITEX network 



_ _] 1 1_ 



addressee 
i i i 



0 10 10 



TYPE DEPENDENT COMPONENT does not exist. 
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6.11 ROAHORD (roaminq order): 


Desiqnated sender: 




The network. 




Designated addressee: 




The mobile terminal. subscription or group. 


Raised flaqs: • 




No raised flags. 




Criteria for qeneratinq the packet: 


The network orders the terminal to send 'ROAM'. 


The network's normal action when receiving the oacket: . 


The network does not normally receive the packet. 


The terminal's normal action when receiving the packet: 


Sends 'ROAM'. 




Lenqth of the packet: 




8 octets. 
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. ROAMORD as generated by the network: 
MP AK -COMMON COMPONENT: 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



_ _ _ _J l 1 — 

sender: the MOBITE X network 

addressee _ 

i I i — i 1 1 — 

10 0 0 0 0 0 



0 10 11 



TYPE DEPENDENT COMPONENT does not exist. 
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6.12 ROAM (roaming message): 


Designated sender: . 




The mobile terminal subscription. 


Designated addressee. 




The network. 




Raised flags: 




No raised flags. 




Criteria for generating the packet: 


The terminal has decided to send 'ROAM' according to the 
roaming algoritm procedure- in the mobile terminal link 
layer or the terminal has received ROAMORD from the 
network. 


The network's normal action when receiving the packet: 


The network registers 'roaming' for the terminal. 
The network also checks the ESN. 


The terminal's normal action when receiving the packet: 


The terminal does not normally receive the packet. 


Length of the packet: 
12 octets. 
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ROAM as generated by the terminal: 
MP AK -COMMON COMPONENT: 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



sender 



addressee: the MOBITEX network 



1 1 



110 0 



T¥PE DEPENDENT COMPONENT: 

1 ! 1_ 

octet 9 -12:. T .._-.. ._ ESN 



_ _I 1 l_ 



4 octets . 

This field states the electronic serial number. 

Fixed terminals without the ESN function should fill 
in the ESN field with zero's (O's). 

For the ESN specification, please refer to Rl-06. 
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6.13 VICESOSRX (re-direction of emergency messages): 


Designated sender: . 




Terminal subscription or personal subscription. 


Designated addressee: 




The network. 




Raised flags: 




No raised flags. 




Criteria for generating the packet: 


The subscriber which is stated the emergency receiver 
wishes that emergency messages (SOSINFO) should be re- 
■ — - directed to the predestinated alternative emergency 
receiver. 


The network's normal action when receivinq the packet: 


The network registers that emergency messages should be 
sent to the alternative emergency receiver. 


The terminal's normal action when receiving the packet: 


The terminal does not normally receive the packet. If the 
operation did not succeed, this should be shown to the 
user. 


Lenqth of the packet: 




8 octets. 
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VICESOSRX as generated by the terminal. 
MPAK-COMMON COMPONENT: 

I L__l L_ _ _ _ _ -J 1 L_ 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



sender 



_1_ 



_1 1_ 



addressee: the MOBITEX network 



0 110 1 



TYPE DEPENDENT COMPONENT does not exist. 
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6.14 SOSRX (cancel of emergency message re-direction): 


Designated sender: 




Terminal subscription or personal subscription. 


Designated addressee: 




The network. 




Raised flaqs: 




No raised flags. 




Criteria for generating the packet: 


The subscriber which is- the emergency receiver wishes to 
resume reception of emergency messages. (SOSINFO) . 


The network's normal action when receiving the packet: 


The network registers that emergency messages should be 
sent to the emergency receiver. 


The terminal's normal action when receiving the packet: 


The terminal does not normally receive the packet. If the 
operation did not succeed, this should be shown to the 
user. 


Length of the oacket: 
& octets. 
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SOSRX as generated by the terminal: 
MPAK- COMMON COMPONENT: 
octet 1-3 s 



sender 



octet 4-6: 
octet 7: 
octet 8: 



_i I i_ _ . 



addressee: the MOB I TEX network 



0 1110 



TYPE DEPENDENT COMPONENT does not exist. 
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6.15 GROUPLIST (list of group MAN): 


Designated sender:. 




The network. 




Designated addressee: 




The terminal subscription 




Raised flags: 




MAILBOX_F 




This packet can be stored in the network's mailbox if the 
addressee cannot be reached even though MAILBOX is not 
included in the subscription service. 


Criteria for generatinq the packet: 


Changes in the subscriber information have taken place, 
the mobile terminal has sent ' BORN 1 or the fixed terminal 
is activated for the first time. 


The network's normal action when receiving the packet: 


The network does not normally receive the packet. 


The terminal's normal action when receiving the packet: 


Replace former list of group numbers with this new group 
list. 


Length of the packet: 
54 octets. 
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GROOPLIST as generated by the network; 
MPAK-COMMON COMPONENT: 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



sender: the MOBITEX network 



addressee 



1 1 



0 1111 



X = «o' or .*1 
TYPE DEPENDENT COMPONENT 
octet 9: 



nurabe: 



octet 10-12: 
octet 13-15: 
octet 16-18: 
octet 19-21: 
octet 22-24: 
octet 25-27: 
octet 28-30: 
octet 31-33: 
octet 34-36: 
octet 37-39: 



MAN 



Of MAN 



(All Terminals Group) 

MAN 2 



,1 



MAN 4 
MAN 5 
MAN 6 
MAN 7 

_MAN 8 
MAN 9 

. MAN 10 



_ _ _] L_ 



Exhibit 2, p. 297 



Cantel Mohitex- 



5i/1056 - A 296 5171/2 Ue 



1990-02-19 



octet 40-42: 
octet 43-45: 
octet 46-48: 
octet 49-51: 
octet 52-54: 



MAN 11 
_MAN 12 

MAN 13 
_MAN 14 

MAN 15 



Note: MAN 1 (octets 10-12) are used for the All Terminals 
Group number. 



Exhibit 2, 



p. 298 



100 



CantelMobitex- 


51/1056 - A 296 5171/2 De 


1990-02-19 A |MTS09A.2 


6.16 FLEXHEQ (list of loqqed-in MAN requested): 


Designated sender: 




The network. 




Designated addressee: 




Terminal subscription. 




Raised flaqs: 




No rasied flags. 




Criteria for generating the packet: 


The network requires current information about which 
subscription that are logged-in at the terminal. 


The network's normal action when receiving the packet: 


The network does not normally receive the packet. 


The terminal's normal action when receiving the packet: 


The terminal sends current information in the ' FLEXLIST ' 
packet. 


Length of the packet: 
6 octets. 
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FLSXREQ as generated by the network; 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



sender: the MOB I TEX network 
_ 1 i_ _ _ _ _ _J l I 



0 0 0 0 



1 0 0 0 0 



TYPE DEPENDENT COMPONENT does not exist. 
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6.17 FLEXLIST (list of personal subscriptions logged-in 
at the terminal) 



Designated sender; 

The network or terminal subscription. 
Designated addressee; 

The terminal subscription or the network. 

Raised flags; 
No raised flags. 

Criteria for generating the packet; 

The network: Changes in information have occurred. 

Terminal: The terminal has received ' FLEXREQ 1 . 

The network's normal action when receiving the packet; 

The network checks the list of personal subscriptions 
logged-in at the terminal. 

The terminal's normal action when receiving the packet; 

Replace former list of personal subscriptions with the : 
list. 



Length of the packet; 
30 octets. 
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FLEXLIST as generated by terminal and network; 



MPAK-C 


OMMON CC 


)MPONEl 


T: 




_J — 1 — 1 — 1 


octet 


,, 








sender 






1 








octet 


4-6: 








addressee 














octet 


7: 


0 0 


0 


0 


0 0 0 0 








1 








octet 


8: 


■ 1 1 


0 


1 


0 0 0 1 





TYPE DEPENDENT COMPONENT: 
octet 9: 



number of MAN 



octet 10-12: 
octet 13-15: 
octet 16-18: 
octet 19-21: 
octet 22-24: 
octet 25-27: 
octet 28-30: 



MAN 4 



_MAN 5_ 
_MAN 6_ 
MAN 7 



No more than 7 subscriptions may be logged-in to one and 
the same terminal. 
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6.18 INFOREQ {terminal information requested!: 


Designated sender: 




The network. 




Designated addressee: 




Mobile terminal subscription. 


Raised flaqs: 




Mo flags raised. ' 




Criteria for generating the packet: 


The network requires updating on terminal information. 


The network's normal action when receiving the packet: 


The network does not normally receive the packet. 


The .terminal's normal action when receiving the packet. 


The terminal sends 1 INFO' 




Length of the packet: 
8 octets. 
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INFOREQ as generated by the network; 
MPAK-COMMON COMPONENT: 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



sender: the MOB I TEX network 

t i - - - - — i 1 1— 

addressee 



0 0 0 0 



10 0 10 



TYPE DEPENDENT COMPONENT does not exist. 
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6.19 INFO (terminal information): 

Designated sender; . 

Mobile terminal subscription. 

Designated addressee: 
The network. 

Raised flags; 
No raised flags. 

Criteria for generating the packet; 
The terminal has received ' INFOREQ 1 . 

The network's normal action when receiving the packet. . 
The network updates the register. 

The terminal's normal action when receiving the packet: 
The terminal does not normally receive the packet. 

Length of the packet; 

The length may vary between 44 and 46 octets. 
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INFO as generated by the terminal: 



octet 1-3: 

octet 4-5: 

octet 7: 

octet 8: 

TXPE DEPI 
octet 9: 

octet 10-12: 

octet 13-15: 

octet 16-18: 

octet 19-21: 

octet 22-24: 

octet 25-27: 

octet 28-30: 

octet 31-44: 



-J 1 l_ ._ _ 



addressee: the MOBITEX network 



_i 1 1 1_ 



number of MAN (personal subs 



MAN 1 (personal subs) 



MAN 2 (personal subs 



MAN 3 (personal subs) 



MAN 4 (personal subs) 



MAN 5 (personal subs) 



MAN 6 (personal subs) 



MAN 7 (personal subs) 



technical information 



octet 45 etc. channel class dep. information 
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technical information : 



14 octets. 



This field states whether the mobile terminal is 
equipped with technical media for generating and 
presenting different traffic types. The field also 
describes the characteristics of the radio station. 
The information to be stated in this field must be 
provided when opening the subscription. 



4: 
5: 



octet 
octet 
octet 
octet 



8 7 6 5 4 



2 1 



med; generate connection 



_i i I i_ 



med: receive connection 



media: present text 



partially active in HBX 



radio :superv. sign, loop 



radio: terminal type 



radio: working method 



radio: output power 



(no=0,yes=l) 
(no=0,yes=l) 
(no=0,yes=l) 
{no=0)See NOTE 
(no=0)See .NOTE 

(Terminal type=3) 

"(duplex=l, 
2-frequency 
simplex=2) 

(WATT) 
(ms) 

See NOTE 

(4 levels, 1-4) 

(spare) 

_ _ (spare) 

i I l l I 

radio: channel class (channel class= 
i — i 1 4 Qr 5 j 

: Octet 4-5 : Part.ially active terminals and speech ■ 
quality supervisory signal are not used. 
FBI (frequency band information, octet 10) is_ 
defined in reference Rl-06. 



radio : rx/tx switch time 



radio: priority 



00000000 



0 0 0 0 0.0 0 
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channel class dependent information: 0-2 octets. 

This field states which radio channels the relevant 
mobile equipment can use. There are 2 possible 
channel classes that may be used; channel class 4 or 
5. 



Channel class 4: 

Pull band station with independent 
channels for receiving and transmitting 
channels . 

Channel class 4 

No channel class dependent information is 
required. 



Channel class 5: 



Pull band station with fixed duplex 
spacing. The duplex spacing is given as 
the channel difference. 

Channel class 5: 



octet 1-2: 



Duplex spacing (channels) 



All figures are binary coded into two octets. The 
most significant bit is bit 8 in the first octet. 
The least significant bit is bit 1 in the second 
octet. 
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6.20 TIME (time information): - 


Desiqnated sender: 




The network. 




Desiqnated addressee: 




The terminal subscription 


or group. 


Raised flags: 




No raised flags. 




Criteria for qeneratinq the packet: 


When traffic load- per-mi-ts, the network sends the network 
time information to the terminals. 


The network's normal action when receiving the packet : 


The network does not normally receive the packet. 


The terminal's normal action when receivinq the packet: 


The time information packet from the network may only be 
used as a calender clock function in the terminal's 
application. 


Length of the packet: 
. 11 octets. 





A23ISIS3.3 
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TIME as generated by the network: 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



sender: the MOB I TEX network 



0 0 0 0 



10 10 0 



_ _ _1 L_ 



octet 9-11: 
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6.21 AREALIST (area ID information] 

Designated sender; . 
The network. 

Designated addressee; 

The mobile terminal subscription. 



Raised flags; 
MAILBOXJ? 

This packet can be placed in the network mailbox if the 
addressee cannot be reached even if MAILBOX is not 
included in the subscription. 

Criteria for generating the packet: 

Changes in the subscriber information concerning the 
operational areas have taken place or the mobile terminal 
has sent 'BORN' . 

The network's normal action when receiving the packet;- 
The network does not normally receive the packet. 

The terminal's normal action when receiving the packet; 

The terminal should forward the area list information to 
the data link layer. 

Length of the packet: 
17 octets. 
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AREALIST as generated by the network: 



octet 1-3:- 
. octet 4-6: 
octet 7: 
octet 8: 



sender: the MOB I TEX network 



addressee 
! I — i — 



1 1 



10 10 1 



TYPE DEPENDENT COMPONENT: 
63 

I 1 !_ - - 

octet 9-15: Bitmap 



_J i L_ 



Command (0-255) 



Bitmap : Bitmap representing the area ID'S. 

The bitmap should be transfered to the data link 
layer. 

0 « not valid area ID. 

1 ■ valid area ID. 



Command : Mobile performance in areas which are indicated 
as not valid in the bitmap. The command should 
also be transfered to the data link layer. 

0 = not valid, area ID's must not be used by 

the terminal. 

1 «■ not valid area ID's may be used, but 

traffic may be charged a different fee. 
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6.22 ESNREQ (Electronic Serial Number recruested) 


Designated sender: 




The network. 




Designated addressee: 




Mobile terminal subscription. 


Raised flags: 




No flags raised. 




Criteria for generating the packet: 


The network requests a check' ef-the electronic serial 
number . 


The network's normal action when receiving the packet: 


The network does not normally receive the packet. 


The terminal's normal action when receiving the packet. 


The terminal sends 'ESNINPO'. 


Length of the packet: 
8 octets. 
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ESNREQ as generated by the network; 
MPAK-COMMON COMPONENT: 
octet 1-3: 



octet 4-6: 
octet 7: 
octet 8: 



sender: the MOBITEX network 



addressee 



10 110 



T¥PE DEPENDENT COMPONENT does not exist. 
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6.23 ESNIHFO (electronic serial number .information: ) 


Designated sender: . 




Mobile terminal subscription. 


Designated addressee: 




The network. 




Raised flags: 




No raised flags. 




Criteria for generating the packet: 


The terminal has received 


' ESNREQ 1 . 


The network's normal action when receiving the packet. 


The network checks the electronic serial number. 


The terminal's normal action when receivinq the packet: 


The terminal does not normally receive the packet. 


Length of the packet: 




12 octets. 
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ESNINFO as generated by the terminal: 
MPAK-COMMON COMPONENT: 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



addressee : the MOB I TEX network 
_i i — 



10 111 



TXPE DEPENDENT COMPONENT: 



octet 9 -12: 



ESN 4 octets. 

This field states the electronic serial number. 
For the ESN specification, please refer to Rl-06. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page{s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Rl-06, 

Ri-oa, 



12, 28, 30, 70, 

13, 17, 21, 25, 



80, 81, 
27, 29, 



92, 108, 117 



Below are the reference designations listed. 

Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04— Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 . Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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Cantel Mobitex~ 


MOB.ITEX 

Network layer for terminals 
Appendix B. DIALOGUES 



ABSTRACT 



This document describes the dialogues between terminals 
and the MOBITEX network. 

Combinations of dialogues are not considered in this 
document and instead, the relevant typical cases in 
communication to/from terminals are described. 
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1 INTRODUCTION 

The dialogues are divided into the following groups : 

PSUBCOM - packet switched subscriber communication 

- Internal traffic without address list {*) 

- Internal traffic with address list (*) 

- Internal traffic to groups (*) 

- External traffic 

* = TEXT, DATA, STATUS, HP-DATA 

PSOSCOM - Packet switched emergency communication 

- Emergency signal/emergency message (SOS, SOSINFO) 
— - Emergency acknoledgement (SOSACK) 

' CSUBCOM - Circuit switched communication 

- Connection and emergency connection (*) 

- External connection (*) 

- Group connection {*) 

- Additional connection (*) 

- Line test (LINEON, LINEOFF) 

* = CONREQ, ADDCONREQ, SOSCONREQ, EXTCONREQ, 

CONFAST, ADDCONFAST, SOSCONFAST, LINSEL 
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DTESERV - Data terminal service communication 
SUBSCRIPTION - STATUS 

- Log-in (LOGINREQ, LOGINGRA , LOGINREF) 

- Log-out (LOGOUT, LOGOUTORD) 



TERMINAL STATUS 

- Activation (ACTIVE) 

- Inactivation (INACTIVE) 

- DIE / LIVE 

- Roaming (ROAM, ROAMORD ) 

- Re-direction of emergency receiver (VICESOSRX) 

- Cancel of re-direction (SOSRX) 



TERMINAL INFORMATION 

- Updating groups (GROUPLIST) 

- Updating area IDs (AREALIST) 

- Updating personal subscriptions (FLEXREQ, 

FLEXLIST) 

- Technical information (INFOREQ, INFO) 

- Time information (TIME) 

- ESN request, ESN information (ESNREQ, ESNINFO) 
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2 INTERNAL TRAFFIC WITHOUT ADDRESS LIST 

The dialogues are identical for all packet switched 
internal traffic without address list. The ' TEXT 1 packet 
in the following dialogues can be replaced by 'DATA', 
'HPDATA' or 'STATUS', without any changes in the dialogue. 

The common factor for all dialogues in internal traffic is 
that the original packet ('TEXT' 1) is generated by the A 
party according to the criteria and with the structure 
described in Appendix A. Reservations are stated for the 
respective dialogues. 



Dialogue 2.1: 

B-party is active and can be reached by the network. 

«' A NETWORK 
' TEXT 1 1 



'TEXT' 2 is identical to 1 TEXT ' 1. 



Exhibit 2, p. 323 



Cantel Mobitex- 


s~ 1 I"" — 

S2/1056 - A 296 5171/2 Ue 


1990-02-23 A | MTS09B.2 


Dialogue 2.2: 



' TEXT 1 L has been generated with subscriber flag 
MAILBOX^FsQ, which indicates that the packet should not be 
stored Tn the network mailbox. 

The B-party is not available at the moment. 



A NETWORK B 

' TEXT ' 1 

' TEXT ' 2 



•TEXT" 2 is returned with traffic state = NO_TRANSFER 

or 

'TEXT' 2 is returned with traffic state = BUSY 

NOTE : This dialogue occurs also when MAIE.BOX_F=l and the 
packet cannot not be stored in the mailbox. A 
packet is not stored in the network mailbox if 
MAILBOX is .not included in B-party's subscription 
service . 
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Dialogue 2.3: 

'TEXT' 1 has subscriber flag MAILBOX_F=l? the packet may 
be stored in the mailbox. 

The B party is not available at the moment. 



■TEXT' 2 



A copy of 'TEXT' 1 is stored in the network mailbox. 
'TEXT' 2 has traffic state = INJiAIL. 

.Packets that are stored in the mailbox .are sent to the 
addressee in accordance with, dialogue 15.2. 

NOTE : If MAILBOX is required by the A-party but MAILBOX 
is not included in the B-party's subscription, the 
packet is returned in accordance with dialogue 2.2. 
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Dialogue 2.4: 

The network has not switched the packet. 



a) The reason why the transfer cannot be performed may be 

1) B party does not exist 

2) the transfer is not permitted due "to the A party's 
subscription 

3) the transfer is not permitted due to the B party's 
subscription. 

'TEXT' 2 is then returned with traffic state ■ ILLEGAL 



b) The network is overloaded. 

'TEXT' 2 is then returned with traffic state = CONGEST 



c) A technical fault has occurred in the network. The 
packet cannot be switched. 

' TEXT 1 2 is then returned with traffic state = ERROR 
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3 INTERNAL TRAFFIC WITH ADDRESS LIST • 

The dialogues are identical for all packet switched 
internal traffic with address list. The 1 TEXT 1 packet in 
the following dialogues can thus be replaced by 1 DATA 1 , 
'HP-DATA' or ' STATUS 1 without any changes in the dialogue. 

The common factor for all dialogue in internal traffic is 
that the the original packet ('TEXT' 1) is generated by 
the A-party according to the criteria and with the 
structure described in Appendix A. Reservations are stated 
for the respective dialogues. 

The network immediately converts ' TEXT * 1 with address 
list to the number of packets stated in the address list. 
Each one of these packets are identical but with different 
addressee. 



Dialogue 3.1: 



Bl B2 B3 B4 



' TEXT 1 2 - 'TEXT '5 etc does not contain an address list. 



AJ3251S13 
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Dialogue 3.2: 



"TEXT'l contains an address list and has subscription flag 
MAILBOX P=0j the packet should not be stored in the 
mailbox? 

One or more of the B-partie3 (Bl and B3 in the example) 
are currently not available. 

A NETWORK Bl B2 B3 B4 

1 TEXT ' 1 



1 TEXT ' 2 



1 TEXT 1 5 



etc. 



' TEXT 1 2 - "TEXT'S etc in the dialogue does not contain an 
address list but have each been allocated an address from 
the address list. 

' TEXT 1 2 and ' TEXT 1 4 has traffic state = NO_TRANSFER or 
traffic state = BUSY. 



NOTE : This dialogue occurs even if MAILBOX is required 

but the packet cannot not be stored in the mailbox. 
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Dialogue 3.3; 

'TEXT'l contains an address list and has subscription flag 
MAILB0X_P = 1. 

One or more of the B parties (B2 and B4 in the example) 
are currently not available. 

A NETWORK Bl B2 B3 B4 



1 TEXT ' 2 



'TEXT' 4 



etc. 



1 TEXT ' 3 



'TEXT '2 - 'TEXT' 5 etc in the dialogue does not contain an 
address list but have each been allocated an address from 
the address list; 

Copies of the packet 1 TEXT ' 3 and 'TEXT* 5 are stored in the 
network mailbox. 

1 TEXT ' 3 and 'TEXT' 5 have traffic state = IN_HAIL. 



NOTE: If MAILBOX is required by the A-party but the 

mailbox service is not included in the B-party's 
subscription, the packet is returned in the same way 
as in dialogue 3.2. 



A 01 SUM 
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Dialogue 3.4 

The network has not switched the packet. 



A NETWORK 
1 TEXT ' 1 



This dialogue shows that 'TEXT' 2 is returned before the 
packet was copied. 'TEXT '2 contains the adress list. 



This dialogue shows that 'TEXT' 2 and ' TEXT 1 3 is returned 

after the original packet has been copied. 

'TEXT'2 and 'TEXT'3 does not contain an addresslist. 



a) The reason why the transfer cannot be performed may be 

1) B party does not exist 

2) the transfer is not permitted due to the A party's 
subscription 

3) the transfer is not permitted due 'to the B party's 
subscription. 

•TEXT'2 (3) is then returned with traffic state = ILLEGAL. 

b) The network is overloaded. 

•TEXT'2 (3) is then returned with traffic state = CONGEST 

c) A technical error has occured in the network. 
'TEXT'2 (3) is then returned with traffic state = ERROR 
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4 INTERNAL TRAFFIC TO GROUPS 

The dialogues are identical for all packet switched 
internal traffic tq groups. The ' TEXT 1 "packets in the 
following dialogue can be replaced by 'DATA', ' HPDATA ' or 
' STATUS ' without any changes in the dialogue common factor 
for all dialogue in internal traffic is that the original 
packet ('TEXT' 1) is generated by the A-party according to 
the criteria and with the structure shown in the Appendix 
A. . 

Since traffic to groups can affect a considerable number 
of subscriptions, the A-party is not notified if any of 
the B-parties is not available. 



Packets to groups are routed to a limited number of 
predetermined base radio stations and fixed terminals. ' 



BAS Bl B2 B3 



In this example, BASE is a predetermined base radio 
station. Bl and B2 are mobile terminals in the group which 
are operating under BASE. B3 is a fixed terminal in the 
group. 

1 TEXT ' 2 and 3 are' copies of 'TEXT' 1. 
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Dialogue 4.2; 

The network cannot transfer the packet. 



•a) The reason why the transfer cannot take place may be 
that the transfer is not permitted in the A party's 
subscription or that the addressed group does not 
exist. 

'TEXT' -2— is - returned with traffic state = ILLEGAL. 



b) The network is overloaded. 

'TEXT* 2 is returned with traffic state = CONGEST 



c) A technical fault has occurred. 

'TEXT' 2 is returned with traffic state = ERROR 
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5 EXTERNAL TRAFFIC 

External traffic applies to traffic with different 
external telecommunications networks. Since the gateways 
to these networks are not yet fully specified, these 
dialogues are excluded. 
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6 EMERGENCY SIGNAL/EMERGENCE MESSAGE 

The 'SOS' packet is generated by the A-party according to 
the criteria and with the structure described in the 
Appendix A. 

The 'SOSINFO' packet is generated by the network according 
to the criteria and with the structure according to 
Appendix A- 

The B-party in these examples are the predestinated 
emergency receiver. 



Dialogue 6.1; 

The B-party is active and can be accessed by the network. 



Dialogue 6.2: 

If both the ordinary and the alternative emergency 
addresses are inactive, no normal transfer of the packet 
can be carried out. The emergency message SOSINFO will 
then be transmitted by the base station where the SOS 
entered the network as shown . in dialogue 6.4. 
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Dialogue 6.3; 

The network has not- been able to transfer the packet to 
the emergency receiver. 

A NETWORK B 



The packet contains incorrect information, for example 
the information about the A party has been incorrectly 
stated. 

'SOS' 2 then has status = ILLEGAL 
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Dialogue 6.4i 

A technical fault has occur ed in the network. 

The emergency signal (SOS) or the emergency message 
(SOSINFO) is re-transmitted by the base radio station 
where the emergency signal entered the network. The 
emergency signal or emergency message is addressed to the 
All Terminals Group MAN. 

CASS 1 

A BASE • mobiles 



1 SOS ' 2 

■SOS' 2 is re-transmitted with traffic state = OK. ' SOS ' 2 
is addressed to All Terminals Group. MAN. 

CASE 2 

A NETWORK mobiles 

'SOSINFO' 2 

'SOSINFO' 2 is re-transmitted with traffic state = OK. 
' SOSINFO' 2 is addressed to the All Terminals Group MAN. 



'SOS' 1 
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7 EMERGENCY ACKNOWLEDGEMENT 

The emergency acknowledge (SOSACK) is generated by the A 
party according to. the criteria and the structure given in 
Appendix A. 

Dialogue 7.1: 

The B-party is active and can be reached by the network. 
A -NETWORK B 

1 SOSACK 1 1 



1 SOSACK ' 2 



' SOSACK ' 1 and 1 SOSACK ' 2 are identical. 



Dialogue 7.2: 

The B-party is can not be reached. 



1 SOSACK ' 2 is returned with traffic state = NO_TRANSFER 
'SOSACK* cannot be stored in the network mailbox. 
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Dialogue 7.3; 

The network cannot transfer the packet. 



a) The reason why the transfer cannot take place could be 
that the B-party does not exist. 

'SOSACK' 2 is then returned with traffic state = ILLEGAL 



b) The network is overloaded. 

' SOSACK ' 2 is then returned with traffic state = CONGEST 



c) A technical fault has occurred. 
•SOSACK" 2 is then returned with traffic state = ERROR 
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8 CIRCUIT SWITCHED CONNE 


CTIQN/EMERGENCY CONNECTION 


In following chapters are CON**R equal to CONREQ 

ADDCONREQ 




EXTCONREQ 




CON**F equal to CONFAST 

ADDCONFAST 
SOSCONFAST 




CON*** equal to CONREQ 

ADDCONREQ 
SOSCONREQ 




EXTCONREQ 
CONFAST 
. ADDCONFAST 
SOSCONFAST 



NOTE 1: The terminal must not enter Speech Mode until 

CON*** sent successfully 

CON**R received and HOOK-OFF received 
from application layer and CONREA sent 
successfully 

CON**F received and HOOK-OFF received 
from application layer 

CONORD received and HOOK-OFF received 
from application layers. 



NOTE 2 j The Receive/Transmit switch of the mobile terminal 
operating in two-frequency simplex must not be 
operational until Speech Mode has been entered. 

3: HOOK-OFF without a previous request for a circuit 
switched connection shall result in an error alarm 
and CONREA shall not be sent to the network. 
HOOK-ON without a previous request for a circuit 
switched connection shall not result in a DISCON 
packet. 



c) 
d) 
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NOTE 4: If there is no HOOK-OFF within 60 seconds from the 
receiving of CON**R, the connection shall be 
concluded by sending "a DISCON. 

If there is no HOOK-OFF within 60 seconds after 
the reception of CONORD, the terminal shall return 
to normal idle state without sending DISCON. 

If there is no HOOK-OFF within 10 seconds from the 
receiving of CON**F, the connection shall be 
concluded by sending a DISCON. 

NOTE 5: The network layer should send Speech-ON to the 
data link layer when 

a) CON*** sent successfully 

or 

b) CON**R received and HOOK-OFF received 
from application layer and CONREA sent 
successfully 

or 

c) C0N**F received 

or 

d) CONORD received.. 

NOTE 6: The terminal should leave Speech_Mode and send 

Speech-OFF to the data 'link layer when a DISCON is 
transmitted by the link layer or when a DISCON is 
returned by the link layer as 'not transmitted'. 
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8.1 Ordinary circuit switched connection 

Dialogue 8.1.1 

A party: Prot_l 

B party: Prot_l or Prot_2A 

.The B party is active and generate HOOK-OFF. 
A-party MBX-network 
'CON**R' (1) 



DIALLED 
SIGNAL 
TO A 



: The connection identity which the A narty 
selects for CON**R (1) shall be included in all 
packets included in this connection (2-5). 



Content of packets : 
CON**R (1) 



Sender : : 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no. : 

Conn . I . D . 



A-PARTY 
B-PARTY 



COK**R (2) 

Sender: 
Addressee: 
Status: 
DIGITAL F: 
EXTERN_F: 
Line no. : 
Conn . I . D . 



A-PARTY 
B-PARTY 



CONREA (3) 

Sender : 
Addressee: 
Status: 
DIGITAL F: 
EXTERN_F: 
Line no. : 
Conn. I.D. 



B-PARTY 
A-PARTY 



DISCON (4) 

Sender : 
Addressee: 
Status : 
DIGITALJF : 
EXTERN_F: 
Line no.: 
Conn. I.D. 
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DISCON (5) 

Sender: 

Addressee: 

Status: 

DIGITAL_F: 

EXTEHtl_F: 

Line no.: 

Conn. I.D. 
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Dialogue 8.1.2 



A party: Prot_l 
B party: Prot_2B 



The B party is active and generate HOOK-OFF. 
A-party MBX-network B-party 

'CON**R' (1) 




■CON**R' 


(2) 






' LINSEL 


(3) 






■CONREA 


(4) 


< 




1 DISCON 


(6) 



The connection identity which the A party 
selects for CON**R (1) shall be included in all 
relevant packets included in the connection (2- 
6) . 



Content of packets 

CON**R (1) 

Sender : : A-PARTY 

Addressee: B-PARTY 

Status : OK 

DIGITAL F: 0 

EXTERNjF: 0 

Line no.: 0 

Conn. I.D. Y 



CON**R (2) 

Sender: 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no.: 

Conn. I.D. 



LINSEL (3) 

Sender: 
Addressee : 
Status: 
DIGITAL F: 
EXTERN F: 
Line no.: 
Conn. I.D. 



B-PARTY 
A-PARTY 
OK 



CONREA (4) 

Sender : 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_P: 

Line no. : 

Conn. I.D. 
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DISCON (5) 




DISCON (6] 




Sender : 


A- PARTY 


Sender : 


B- PARTY 


Addressee: 


B-PARTY 


Addressee: 


A-PARTY 


Status : 


OK 


Status: 


OK 


DIGITALS: 


0 


DIGITAL_F: 


0 


EXTERN_F: 


0 


EXTERN_F : 


0 


Line no. : 


0 


Line no. : 


z 


Conn. I.D. 


X 


Conn. I.D. 


X 
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Dialogue 8.1.3 

A party: Prot_l 

B party: Prot_l or Prot_2A 

The B party is active and generate HOOK-OFF. 

A-party MBX-network 

'CON**F' (1) 



: The connection identity which the A party 
selects for CON**F (1) shall be included in all 
relevant packets included in the connection 
(2-4) 



Content of packets: 
C0N**F (1) 



Sender : : 
Addressee: 
Status: 
DIGITAL F: 
EXTERN F: 
Line no. : 
Conn. I.D. 



A-PARTY 
B-PARTY 



CON**F (2) 

Sender : 
Addressee: 
Status : 
DIGITAL_F : 
EXTERN_F : 
- Line no. : 
Conn . I.D. 



DISCON (3) 

Sender: 
Addressee: 
Status: 
DIGITAL F: 
EXTERN_F: 
Line no.: 
Conn. i.D. 



DISCON (4) 

Sender: 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no. : 

Conn. I.D. 



A-PARTY 
B-PARTY 
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Dialogue 8.1.4 

A party: Prct_l 
B party: Prot_2B 

The B party is active and generate HOOK-OFF. 
A-party MBX-network B-party 

'CON**F' (1) 

'CON**F' (2) 








' LINSEL ' 


(3) 






■DISCON' 
< " 


(5) 



COMMENT : The connection identity which the A party 

selects for CQN**F (1) shall be included in all 
relevant packets included in the connection (2- 
5). 

Content of packets: 
CON**F (1) 



Sender: : 
Addressee: 
Status: 
DIGITAL F: 
EXTERN_F: 
Line no. : 
Conn. I.D. 



(3) 

Sender: 
Addressee: 
Status: 
DIGITAL_F: 
EXTERN_F: 
.Line no. : 
Conn. I.D. 



OK 



CON**F (2) 

Sender : 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no. : 

Conn. I.D. 



DISCON (4) 

Sender: 
Addressee: 
Status: 
DIGITAL_F: 
EXTERN_F : 
Line no. : 
Conn. I.D. 



A-PARTY 
B-PARTY 



Exhibit 2, p. 346 



30 



Cantel Mobitex- 



52/1056 - A 296 5171/2 Oe 



1990-02-23 A 



D1SCON (5) 

Sender: B-Pi 

Addressee: A-Pi 

Status: OK 

DIGITAL/: 0 

EXTERN_Fs 0 

Line no. : Z 

Conn. I.D. Y 



AJ33SISW 
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8.2 B-party disconnects the call 



Dialogue 8.2.1 

A party: Prot_l 

B party: Prat_l or Prot_2A 

The B party is active and generate HOOK-OFF. The B party 
disconnects with HOOK-ON. 



A-party MBX-network 
'COH**R' (1) 



'DISCON' (5) 



DIALLED 
SIGNAL 
TO A 



CON**R (1) 

Sender: 
Addressee: 
Status : 
DIGITAL_F: 
EXTERN_F: 
Line no . : 
Conn. I.D. 



A-PARTY 
B-PARTY 
OK 



CON**R (2) 

Sender: 
• Addressee: 
Status: 
DIGITAL_F: 
EXTERN_F: 
Line no. : 
Conn. I.D. 



A-PARTY 
B-PARTY 



(3) 

Sender : 

Adressee: 

Status: 

DIGITAL_F: 

EXTERN^F: 

Line no. : 

Conn. I.D. 



B-PARTY 
A— PARTY 



DISCON (4) 

Sender : 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no.: 

Conn. I.D. 
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DISCON (5) 

Sender s B-PARTY 

Addressee: A-PARTY 

Status : OK 

DIGITAL_F : 0 

EXTERN_P: 0 

Line no.: 0 

Conn. I.D. Y 
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Dialogue 8.2.2 



A party: Prot 1 
B party: Prot~2B 



The B party is active and generate HOOK-OFF. The B-party 
disconnects with HOOK-ON. 



A-party 

'CON**R' (1) 



MBX-network 



'DISCON' (6) 



DIALLED 
SIGNAL 
TO A 



'CON**R' (2) 



CON**R (1) 

Sender : 
Addressee: 
Status: 
DIGITAL_F: 
EXTERN F: 
Line no. : 
Conn. I.D. 



CON**R [2} 

Sender: 
Addressee: 
Status: 
DIGITAL F: 
EXTERN_F: 
Line no.: 
Conn. I.D. 



LINSEL (3) 

Sender : 
Adressee: 
Status: 
DIGITAL F: 
EXTERN_F: 
Line no. : 
Conn. I.D. 



CONREA (4) 

Sender : 
Adressee: 
Status: 
DIGITAL_F : 
EXTERN_F: 
Line no.: 
Conn. I.D.. 



Exhibit 2, p. 



Cantel Mobitex- 



• A 296 5171/2 Ue 



1990-02-23 A 



DISCON (S) 




DISCON (6) 




Sender : 


B— PARTY. 


Sender : 


B-PARTY 


Addressee: 


A-PARTY 


Addressee: 


A- PARTY 


Status : 


OK 


Status: 


OK 


DIGITAL F: 


0 


DIGITAL_F: 


0 


EXTERN_P: 


0 


EXTERN_F: 


0 


Line no.: 


z 


Line no.: 


0 


Conn. I.D. 


Y 


Conn. I.D. 


Y 
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Dialogue 8.2.3 

A party: Prot_l 

B party: Prot_l or Prot_2A 

The B party is active and generate HOOK-OFF. The B-party 
disconnects the call with HOOK-ON. 



MBX-network 



'CON**F' (1) 



'DISCON' (4). 



TION IN 
PROGRESS 



■CON**F' (2) 



CON**F (1) 

Sender : 

Addressee: 

Status: 

"DIGITAL_F: 

EXTERN_F: 

Line no.: 

Conn. I.D. 



DISCON (3) 

Sender : 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no. : 

Conn. I.D. 



B-PARTY 
A-PARTY 



CON**F (2) 

Sender: 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no. : 

Conn. I.D. 



DISCON (4) 

Sender : 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no. : 

Conn. I.D. 



A-PARTY 
B-PARTY 
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Dialogue 8.2.4 

A party: Prot_l 
B party: Prot_2B 

The B party is active and generate HOOK-OFF. The B-party 
'disconnects the call with HOOK-ON. 



MBX-network 



CONNEC- 
TION IN 
PROGRESS 




CON**F (1) 

Sender : 
Addressee: 
Status: 
DIGITAL F: 
EXTERN F: 
Line no.: 
Conn. I.D. 



A-PARTY 
B-PARTY 



C0N**F (2) 

Sender: 
Addressee : 
Status: 
DIGITAL_F: 
EXTERN F: 
. Line no . : 
Conn. I.D. 



LINSEL (3) 

Sender : 

Adressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line ho . : 

Conn. I.D. 



DISCON (4) 

Sender: 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no. : 

Conn. I.D. 
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DISCON (5) 

Sender: B-PARTY 

Addressee: A-PARTY 

Status : OK 

DIGITAL_P: 0 

EXTERN_F : 0 

Line no. : 0 

Conn. I.D. Y 
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8.3 A-party disconnects the call. 



Dialogue B.3.1 



A party: Prot_l 

B party: Prqt_l or Prot_2A 



• The B party is active and generate HOOK-OFF. The A-party 
disconnects the call with HOOK-ON. 

A-party MBX-network . B-party 



DIALLED 
SIGNAL 
TO A 



CONNEC- 
TION IN 
PROGRESS 




C0N"**R (1) 

Sender : 
Addressee: 
Status : 
DIGITAL_F: 
EXTERN_F: 
Line no.: 
Conn . I . D . 



C0N**R (2) 

Sender: 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no . : 

Conn. I.D. 



CONREA (3) 

Sender : 
Addressee: 
Status: 
DIGITAL_F: 
EXTERN F: 
Line no.: 
Conn. I.D. 



DISCON (4) 

Sender: 
Addressee: 
Status: 
DIGITAL_F: 
EXTERN_F : 
Line no.: 
Conn. I.D. 
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DISCON (5) 

Sender : A-P-ARTY 

Addressee: B-PARTY 

Status: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no. : Z 

Conn. I.D. Y 
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Dialogue 8.3.2 



A party: Prot_l 
B party: Prot~2B 



The B party is active and generate HOOK-OFF. The A-party 
disconnects the call with HOOK-ON. 



MBX-network 



DIALLED 
SIGNAL 
TO A 



'CON**R' (2) 



CON**R (1) 

Sender : 
Addressee: 
Status: 
DIGITAL_F : 
EXTERN_F: 
Line no.: 
Conn. I.D. 



LINSEL (3) 

Sender : 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no. : 

Conn. I.D. 



CON**R (2) 

Sender : 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no. : 

Conn. I.D. 



CONREA (4) 

Sender: 
Addressee: 
Status: 
DIGITAL_F: 
EXTERN_F : 
Line no. : 
Conn. I.D. 
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Sender : 
Addressee: 

Status: 
DIGITAL_P: 
EXTERN_F: 
Line no.: 
Conn. 1.0. 



Sender: 
Addressee: 

Status: 
DIGITAL_F: 
EXTERN_F: 
Line no. : 
Conn. I.D. 
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Dialogue 8.3.3 



A party: Prot_l 

B party: Prot_l or Prot_2A 



The B party is active and generate HOOK-OFF. The A-party 
disconnects the call with HOOK-ON. 



MBX-network 



CON**F (1) 

Sender : A-FARTY 

Addressee : B-PARTY 

Status : OK 

DIGITAL_F : 0 

EXTERN F: 0 

Line no. : 0 

Conn. I.D. Y 



CON**F (2) 

Sender : A-PARTY 

Addressee: B-PARTY 

Status : OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no.: Z 

Conn. I.D. Y 



DISCON (3) 

Sender : A-PARTY 

Addressee: B-PARTY 

Status: OK 

DIGITAL F: 0 

EXTERN_F: 0 

Line no. : 0 

Conn. I.D. Y 



DISCON (4) 

Sender : A-PARTY 

Addressee: B-PARTY 

Status: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no.: Z 

Conn. I.D. Y 
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Dialogue 8.3.4 



A party: Prot 1 
B party: Prot~2B 



The B party is active and generate 
disconnects the call with HOOK-ON. 



A-party 




CON**F (1) 

Sender : 
Addressee: 
Status: 
DIGITAL P: 
EXTERN_F: 
Line no. : 
Conn. I.D. 



CON**F (2) 

Sender: 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no . : 

Conn. I.D. 



A-PARTY 
B— PARTY 
OK 



LINSEL (3) 

Sender: 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line no. : 

Conn. I.D. 



DISCON (4) 

Sender: 
Addressee: 
Status : 
DIGITAL_F: 
EXTERN_F: 
Line no.: 
Conn. I.D. 



A-PARTY 
B-PARTY 
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DISCON (5) 

Sender: A-PARTY 

Addressee : B-PARTY 

Status : OK 

DIGITAL F: 0 

EXTEHN_F: 0 

Line no. : Z 

Conn. I.D. X 
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8.4 The network disconnects the call. 



The network disconnects a call only in exceptional cases. 
This occurs after a 'hurry up' tone during high traffic 
loading and in the case of faults. 

A party: Prot_l 
' B party: Prot_l or Prot_2A 

The B party is active and answers. 

The real time connection is connected between. the parties. 
Neither of the parties has requested for a disconnection. 

A-party MBX-network B-party 




CON**R (1) 

Sender : A-PARTY 

Addressee: B-PARTY 

Status: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no. : 0 

Conn. I.D. Y 



CON**R (2) 

. Sender: A-PARTY 

Addressee: B-PARTY 

Status : OK 

DIGITAL F: 0 

EXTERN_F: 0 

Line no . : Z 

Conn. I.D. Y 



CONREA (3) 

Sender : 
Addressee : 
Status: 
DIGITAL_F: 
EXTERNJF: 
Line no. : 
Conn. I.D. 



DISCON (4) 

Sender : 
Addressee: 
Status: ■ 
DIGITAL_F: 
EXTERN_F : 
Line no.: 
Conn. I.D. 
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DISCON (5) 

Sender : MBX 

Addressee: A-PARTX 

Status: OK 

DIGITAL F: 0 

EXTERN_F: 0 

Line no.: 0 

Conn. I.D. X 



A232S15M 
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8.5 B-party does not reply. 

Dialogue 8.5.1 

A party: Prot_l 

B party: Prot_l or Prot_2A 

B-party is active but does not generate HOOK-OFF. 
A-party generates HOOK-ON. 



A-party 

' CON**R" (1) 



(1) 

Sender : 

Addressee: 

Status: 

DIGITAL_F: 

EXTERN_F: 

Line ho . : 

Conn. I.O. 



DISCON (3) 

Sender: 
Addressee : 
Status: 
DIGITAL_F: 
EXTERN_F : 
Line no. : 
Conn. 1.0. 



MBX-network 



DIALLED 
SIGNAL 
TO A 



CON**R (2) 

Sender : 
Addressee : 
Status: • 
DIGITALJ?: 
EXTERN_F: 
Line no. : 
Conn. Z.D. 



DISCON (4) 

Sender : 
Addressee: 
Status : 
DIGITAL_F: 
EXTERN_F: 
line no.: 
Conn. I.D. 



'CON**R' (2) 



A-PARTY 
B-PARTY 



A-PARTY 
B PARTY 
OK 
0 
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Dialogue 3.5.2 

A party: Prot_l 

B party: Prot_l or Prot_2A 

The B-party is active but does not reply. 

The A party does not generate HOOK-ON (A party does not 
•disconnect the call). 

A-party MBX-network B-party 



'CON**R' (2) 




CON**R (1) 

Sender : 
Addressee: 
Status: 
DIGITAL F: 
EXTERN_F: 
Line no.: 
Conn. I.D. 



CON**R (2) 

Sender: 
Addressee: 
Status: ' 
DIGITAL F: 
EXTERN_F: 
Line no.: 
Conn. I.D. 



DISCON (3) 

Sender : 
Addressee: 
Status: 
DIGITAL F: 
EXTERN_F: 
Line no. : 
Conn. I.D. 



HBX 

A-PARTY 



DISCON (4) 

Sender: 
Addressee : 
Status: 
DIGITAL_F : 
EXTERN_F: 
Line no. : 
Conn . I.D. 
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.6 A-party with several line connections 



Dialogue 8.6.1 

A party: Pcot_2A 

B party: ProtJ. or Prot_2A 

The B party is active and generates HOOK-OFF. 
A-party MBX-network 



DIALLED 
SIGNAL 
TO A 



CON**R (1) 

Sender: 
Addressee: 
Traf State 
DIGITAL F: 
EXTERN/: 
Line no. : 
Conn. I.D. 



CONGRA (2) 

Sender : 
Addressee: 
- Traf State 
DIGITAL_F: 
EXTERN_F : 
Line no. : 
Conn. I.D. 



CON**R (3) 

Sender: 
Addressee: 
Traf State: 
DIGITAL_F: 
EXTERN_F : 
Line no. : 
Conn. I.D. 



CONREA (4) 

Sender: 
Addressee: 
Traf State: 
DIGITAL_F: 
EXTERNJ?: 
Line no.: 
Conn. I.D. 



B-PARTY 
A-PARTY 
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OISCOH (5) 

Sender: B-PARTY 

Addressee: A-PARTY 

Traf State: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no.: Z 

Conn. I.D. Y 



DISCON (6) 

Sender: A-PARTY 

Addressee: B-PARTY 

Traf State: OK 

DIGITAL_F: 0 

EXTERNJF: 0 

Line no. : W 

Conn. I.D. Y 
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Dialogue 8.6.2 

A party: Ptot_2B 

B patty: Prot_l or. Prot_2A 

The B party is active and generates HOOK -OFF. 
A-party MBX-network . B-party 

'CON**R' (1) 



DIALLED 
SIGNAL 
TO A 



CONNEC- 
TION IN 



*CON**R' (2) 



CON**R (1) 

Sender : 
Addressee: 
Traf State: 
DIGITAL_F: 
EXTERN_F: 
Line no . : 
Conn. I.D. 



(3) 

Sender : 
Addressee: 
Traf State: 
DIGITAL F: 
EXTERN.?: 
Line no. : 
Conn . I.D. 



A-PARTY 
B-PARTY 



B-PARTY 

A-PARTY 

OK 

0 

0 



C0N**R (2) . 

Sender : 
Addressee: 
Traf State: 
DIGITAL_F: 
EXTERN F : 
Line no.: 
Conn. I.D. 



DISCON (4) 

Sender: B-Pi 
Addressee: A-PJ 
Traf State: OK 
DIGITAL F: 0 



Line no. 
Conn. I.I 
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D1SC0N (5) 

Sender: A-PARTY 

Addressee: B-PARTY 

Traf State: OK 

DIGITAL F: 0 

EXTERN_F: - -0 

Line no.: W 

Conn. I.D. Y 
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8.7 Conflicting connection requests. 

Dialogue 8.7.1 

A party: Prot_l 

B party: Prot_l or Prot_2A 

B party has one free line 

The B party is active and answers. 

A-party MBX-network 



'CON**R' (1) 



DIALLED 
SIGNAL 
TO A 



CONNEC- 
TION IN 



'CON**R' 
(2) 



' CON** 1 
(3) 



> <- 




' CONREA 1 


(4) 


< 




1 CON*** 1 


(5) 



etc. 

COMMENT : The network always has priority with calls to 

terminals Prot_l and Prot_2A. In the case above, 
the network returns CON*** (3). With che aid of 
conn I.D., sender and addressee, the terminal 
must be able to see that order 5 does not apply 
to the current connection. 

Note that the sequence of orders 4 and 5 can be reversed. 



CON**R (1) 




C0N**R (2) 




Sender : 


A-PARTY 


Sender : 


A-PARTY 


Addressee: 


B -PARTY 


Addressee: 


B-PARTY 


Traf State: 


OK 


Traf State: 


OK 


DIGITAL F: 


0 


DIGITAL F: 


0 


EXTERN F: 


0 


EXTERN_F : 


0 


Line no . : 


0 


Line no . : 


z 


Conn. i.d. 


Y. 


Conn . I.D. 


Y 



& 292 3153*3 
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CON*** (3) 

Sender : B-PARTY 

Addressee: 1 C-PARTY ' 

Traf Shate: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no. : 0 

Conn. I.D. 0 



CONREA (4) 

Sender: B-PARTY 
Addressee: . A-PARTY 
Traf State: OK 
DIGITALJE": 0 
EXTERN_F: 0 
Line no.: Z 
Conn. I.D. Y 



CON*** (5) 

Sender: 
Addressee: 
Traf State: 
DIGITAL_F: 
EXTERN F: 
Line no. : 
Conn. I.D. 



B-PARTY 
' C-PARTY 1 
CONGEST 
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Dialogue 8.7.2 

A patty: Prot 1 
B party: Prot~2B 

B party has one free line 

The B party is active and answers. 

A-party MBX-network 

■C0N**R' (1) 



DIALLED 
SIGNAL 
TO A 



'CON**R' 
(2) 



1 CON** 
(3) 



COMMENT : Terminal Prot_2B has priority with calls to the 
network. In the case above; the terminal sends 
DISC0N(4) as response- to CON**R<2). Signal 
CON*** reach C-party. 



CON**R (l) 

Sender: A-PARTY 

Addressee: B-PARTY 

Traf State: OK 

DIGITAL_F: 0 

EXTERN F: 0 

Line no. : 0 

Conn. I.D. Y 



C0N**R (2) 

Sender: 
Addressee: 
Traf State: 
DIGITAL_F : 
■ EXTERN F: 
Line no. : 
Conn. I.D. 



A-PARTY 
B-PARTY 



dont care=H 



CON*** (3) 

Sender : B-PARTY 

Addressee: 'C-PARTY* 

Traf State: OK 

DIGITAL F: 0 

EXTERN_F: 0 

Line no. : N 

Conn. I.D. D 



DISCON (4) 

Sender: B-PARTY 

Addressee: A-PARTY 

Traf State: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no. : H 

Conn. I.D. y 
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DISCON (5) 

Sender: B-PARTY 

Addressee : A-PARTY 

Traf State: OK 

DIGITAL F: 0 

EXTERN_F: 0 

Line no. : 0 

Conn. I.D. X 
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Dialogue 8.7.3 



A party: Prot_l 
B party: Prot_2A 

B party has more than one line free for real time 
connection. 

The B party is active and answers. 



MBX-network 



'CON**R' (1) 



DIALLED 
SIGNAL 
TO A 



*CON**R' 
(2) 



1 CON*** 1 
(3) 



CONNEC- 
TION IN 
PROGRESS 
etc. 

COMMENT : In the case above, the calls are treated 
independently of each other. 

Note that the sequence of orders 4 and 5 can be reversed. 



CON**R (1) 

Sender: A-Pi 

Addressee: B-Pi 

Traf State: OK 

DIGITAL F: 0 

EXTERN_F: 0 

Line no.: 0 

Conn. I.D. Y 



CON**R (2) 

Sender : 
Addressee: 
Traf State: 
• DIGITAL_F: 
EXTERN_F: 
Line no.: 
Conn. I.D. 



CON*** (3) 



Sender : 
Adddressee: 
Traf State: OK 
DIGITAL_F: 
. EXTERN_F: 
Line no. : 
Conn. I.D. 



B-PARTY 
C-PARTY* 



(4) 

Sender : 
Addressee: 
Traf State: 
DIGITAL_F: 
EXTERN_F: . 
Line no.: 
Conn. I.D. 
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CONGRA (5) 

Sender: ' C-PARTY ' 

Addressee: B-PART 

Traf State: OK 

DIGITAL P: 0 

EXTERN_F: 0 

Line no.: 7 

Conn. I.D. D 
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Dialogue 8.7.4 

A party: Prot 1 
B party: Prot~2B 

B party has more than one line free for real time 
connection. 

The B party is active and answers. 
A-party MBX-network B-pi 

■CON **R' (1) 

'CON**R' ' CON*** 1 
(2) (3) 



DIALLED 
SIGNAL 
TO A 



TION . IN 
OGFJ 
etc, 



' CONREA ' (5) 



COMMENT : In the case above, the calls are treated 
independently of each other. 



CON**R (1) 

Sender: 
Addressee: 
Traf State: 
DIGITAL_F: 
EXTERN_F: 
Line no. : 
Conn. I.D. 



A-PARTY 
B-PARTY 



CON**R (2) 

Sender : 
Addressee: 
Traf State: 
DIGITAL_F: 
• EXTERN_F: 
Line no . : 
Conn . I.D. 



A-PARTY 
B-PARTY 



CON*** (3) 

Sender: . B-PARTY 

Adddressee: ' C-PARTY ' 

Traf State: OK 

DIGITAL F: 0 

EXTERN_F: 0 

Line no. : N 

Conn. I.D. 0 . 



LINSEL (4) 

Sender: B-FARTY 

Addressee: A-PARTY 

Traf State: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no. : Z 

Conn. I.D. Y 
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CONREA (5) 




Sender : 


B-PARTY 


Addressee: 


A-PARTY 


Traf State: 


OK 


DIGITAL F: 


0 


EXTERN F: 


0 


Line no.: 


Z 


Conn. I.D. 


X 



feproa 



Exhibit 2, p. 





Cantel Mobitex- 


52/1056 -A 296 5171/2 Oe 


*1990M)2-23 'a | MTS09B.2 



8.8 Conflicting disconnection orders. 
Dialogue 8.8.1 



A party: Prot_l 

B party: ProtJL or Prot_2A 

The B-party is active and answers. The A-party and B-party 
both disconnect the real time connection but not at the 
same time. 



DIALLED 
SIGNAL 
TO A 




'DISCON' 
(6) 



'DISCON' 
(5) 



COMMENT : After the B-party has sent DISCON (5), the B- 
party considers the connection is no longer in 
operation. Since the connection no longer exists- 
when the B party accepts DISCON (6), this packet 
can be ignored.- 



CON**R (1) 




CON**R (2) 




Sender : 


A-PARTY 


Sender: 


A-PARTY 


Addressee : 


B-PARTY 


Addressee: 


B-PARTY 


Traf State: 


OK 


Traf State: 


OK 


DIGITAL F: 


0 


DIGITAL F: 


0 


EXTERN F: 


0 


EXTERNF: 


0 


Line no. : 


0 


Line no.: 


z 


Conn . I . D . 


Y 


Conn. I.D. 


Y 
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CONREA (3) 




DISCON (4) 




Sender : 


B-PARTY 


Sender: 


A-PARTY 


Addressee: 


A-PARTY 


Addressee : 


B-PARTY 


Traf State: 


OK 


Traf State: 


OK 


DIGITAL F: 


0 


DIGITAL F: 


0 


EXTERN_F: 


0 


EXTERN_F: 


0 


Line no. : 


z 




0 


Conn. I.D. 




Conn. I.D. 


Y 


DISCON (6) 




DISCON (5) 




Sender : 


A— PARTY 


Sender : 


B-PARTY 


Addressee: 


B-PARTY 


Addressee: 


A-PARTY 


Traf State: 


OK" 


Traf State: 


OK 


DIGITAL_F: 


0 


DIGITAL_F: 


0 


EXTERN_F: 


0 


EXTERN_F : 


0 


Line no.s 


Z 


Line no . : 


Z 


Conn. LO- 


Y 


Conn. I.D. 


Y 
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a. 9 B-party's reply doe 


s not reach the network 


Dialogue 8.9.1 





A party: Prot_l 

B party: Prot_l or Prot_2A 

The B-party is active but does not make contact with the 
network when the request has been received. 



DIALLED 
SIGNAL 
TO A 



The CONREA packet does not reach the network, 
the B-party shall then consider that the CON**R 
signal has not been received. 



CON**R (1) 

Sender : A-PARTY 

Addressee: B-PARTY 

Traf State: OK 

DIGITAL_F: 0 

EXTERN F: 0 

Line no.: 0 

Conn. I.D. Y 



CON**R (2) 




Sender : 


A- PARTY 


Addressee: 


B-PARTY 


Traf State: 


OK 


DIGITAL F: 


0 


EXTERN_F: 


0 


Line no . : 


Z 


Conn. I.D. 


Y 



(3) 

Sender : B-PARTY 

Addressee: A-PARTY 

Traf State: OK 

DIGITAL_P: 0 

EXTERN_F: 0 

Line no.: Z 

Conn. I.D. Y 
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8.10 Connection request returned by the network 

A returned request can be caused by : 

1) B-party is not active 

2) A-party lacks the service 

3) technical error in the network 
4] network is overloaded 

etc. 

Dialogue 8.10.1 
A-party: Prot_l 



MBX-network 



If a terminal accepts CON*** with a traffic 
state that is not OK, this should be considered 
as a DISCON. 



CON*** (1) 

Sender : A-PARTY 

Addressee: B-PARTY 

Traf State: OK 

DIGITAL F 0 

EXTERN_Fj 0 

Line no. s 0 

Conn. I.D. Y 



Sender : 
■ Addressee: 
Traf State: 



Line no.: 
Conn. I.D. 



A-PARTY 
B-PARTY 

NOJTRANSFER 
or ILLEGAL 
or CONGEST 
or ERROR 
or BUSY 
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Dialogue 8.10.2 
A-party: Prot_2B 



MBX-network 



COMMENT : If a terminal accepts CON* * * with a traffic 

state that is not OK, it should be considered ; 
a DISCON. 



CON*** (1) 

Sender : A-PARTY 

Addressee : B-PARTY 

Traf State: OK 

DIGITAL F 0 

EXTERN/: 0 

Line no.: W 

Conn. I.D. ¥ 



Sender: 
Addressee: 
Traf State: 



A-PARTY 
B— PARTY 

NOJTRANSFER 
or ILLEGAL 
or 



DIGITAL_F: 
EXTERN_F : 
Line no. : 
Conn. I.D. 
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Dialogue 8.10.3 



A-party: Ptot_2A 



Two cases are possible: 
Case 1: 

A-party MBX-network . . B-party 

'CON***' (1) '*" 

'CON***' (2) 



COMMENT : If a terminal receives CON*** with a traffic 

State that is not OK, it should be considered as 
' a DISCON. 



MBX-network 



' CONGRA ' (2) 



If a terminal receives CON*** with a traffic 
state that is not OK, it should be considered as 
a DISCON. 



CON** 



(1) 



Sender: A-PARTY 

Addressee: B-PARTY 

Traf State: OK 

DIGITAL F 0 

EXTERN_F: 0 

Line no . : 0 

Conn. I.D. Y 



CONGRA (2) 

Sender : B-PARTY 

Addressee: A-PARTY 

Traf State: OK 

DIGITAL_F: 0 

EXTERN F: 0 

line no, : W 

Conn. I.D.: Y 
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CON*** (3) 

Sender : A— PARTY 

Addressee: B-PARTY 

Traf State: NOJTRANSFER 
or ILLEGAL 
or CONGEST 
or ERROR 
or BUSY 

DIGITAL P 0 

EXTERN F: 0 

Line no.: W 

Conn. I.D. Y 
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8.11 Nan ordinary disconnect 

This kind of disconnect is used when the network for some 
reason has lost the registration of connections. 



Dialogue 8.11.1 

A-party: Prot_l 
B-party: Prot_l 



A-party 



MBX-network 



•DISCON" (1) 



DISCON (1) and (2) 
Sender : MBX 

Addressee: All terminal group man or 

Fixed terminal man 
Traf State: OK 
DIGITAL F 0 
EXTERN_F: 0 
Line no . : 0 
Conn. I.D. 0 

COMMENT : Terminals shall always disconnect when receiving 
the DISCON. 
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Dialogue 8.11.2 



A-party: Prot_2A or Prot_2B 
B-party: Prot_2A or Prot_2B 



MBX-networlc 



DISCON (1) and (2) 
Sender: MBX 

Addressee: Fixed terminal man 

Traf State: OK 

DIGITAL F 0 

EXTERN_F: 0 

Line no. : Z 

Conn. I.D. 0 

COMMENT : Terminals shall always disconnect when receiving 
this DISCON. Line number Z is in range 1 to N. 
N is maximum number of lines to this fixed 
terminal. 
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8.12 Request for non ordinary disconnect. 



This kind of disconnect is used when the terminal has lost 
the registration of connections. 

Valid for fixed terminal Prot_2A or Prot_2B. 

Fixed term MBS-network 
'DISCON' (1) 



'DISCON' (3) 



•DISCON* (N+l) 



Sender: Fixed term 

Addressee: MBX 

Traf State: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no. : 0 

Conn. I.D. 0 



DISCON (2) 

Sender : MBX 

Addressee: Fixed terra 

Traf state: OK 

DIGITAL_F: 0 

- EXTERN_F : 0 

Line no.: 1 

Conn, I.D. 0 



DISCON (3) 

Sender: 
Addressee: 
Traf State: 
DIGITAL_F: 
EXTERN_F: 
Line no. : 
Conn. I.D. 



DISCON (N) 

Sender : MBX 

Addressee: Fixed term 

Traf state: OK 

DIGITAL_F: 0 

EXTERN_F: 0 
Line no.: 
Conn. I.D. 



N-l 
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DISCON (N+l) 

Sender : MBX 

Addressee: Fixed term 

Traf State: OK 

DIGITAL_P: 0 

EXTERN_F: 0 

Line no.: N 

Conn. I.D. 0 



Terminals shall always disconnect when receiving 
this DISCON. N is maximum number of lines to 
this fixed terminal. Only fixed. terminals with 
more" than one line may send DISCON(l). 
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8.13 Request for connection to unknown B-party 

The addressee in CON*** is unknown in the terminal, e.g. 
personal subscription has just logged out. 

Instead of a CONREA or a returned CON* * * , the terminal 
should send a DISCON with the subscriber flag ONKNOWN_F=l. 



MBX-network 




i The connection identity which the A-party 
selects for CON*** (1) shall be included in all 
orders processed by the relevant connection. 
Orders 2-4 in this case. 



CON*** (1) 

Sender : : A-PARTY 

Addr es see : B-PARTY 

Traf State: OK 

DIGITAL_F: 0 

EXTERN F: 0 

Line no. : 0 

Conn.' I.D, Y 



CON*** (2) 

Sender : A-PARTY 

Addressee: B-PARTY 

Traf State: OK 

DIGITAL F: 0 

EXTERN_F: 0 

Line no. : Z 

•Conn. I.D. Y 



DISCON (3) 

Sender : B-PARTY 

Addressee: A-PARTY 

Traf State: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

UNKNOWN F: 1 

Line noT: z 

Conn. I.D. Y 



CON*** (4) 

Sender : A-PARTY 

Addressee : B-PARTY 

Traf State: NO TRANSFER 

DIGITAL_F: 0 

EXTERN_F: 0 

DNKNOWN_F: 0 

Line no.: 0 

Conn. I.D. Y 
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8.14 Enable / disable lines for fixed terminals 

This kind of enable and disable is used when a fixed 
terminal, for some -reason, does not want the network to 
connect on a special line. 



Fixed terminal Prot_2A. 



Case 1: 

Fixed terminal MBX-network status of line Z 



LINEOFF (1) 

Sender: Fixed terminal 

Addressee: HBX 

Traf State: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no. : Z 



LINEON (2) 

Sender : 
Addressee: 
Traf State 
DIGITAL_F: 
EXTERN_F: 
Line no.: 



Fixed terminal 
HBX 



NOTE : The network may send packets CSUBCOM.CLOOPON and 
CSUBCOM.CLOOFOFF during the time in disabled mode. 
See Appendix B-ll. 



A 232 5153-3 
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Case 2: 

Fixed terminal MBX-network status of line I 



LINEOFF (1) 

Sender: Fixed terminal 

Addressees MBX 

Traf State: OK 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no.: Z 



DISCON (2) 

Sender: MBX 

Addressee: Fixed terminal 

Traf state OK 

DIGITAL_F: 0 

EXTERN F: 0 

Line no . : Z 

Conn. t.D. 0 



COMMENT : DISCON(2) is of type "Non ordinary disconnect". 
If the fixed terminal wants the network to 
disable the line after receiving DISCON(2), it 
has to send LINEOFF(l) again. 
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9 EXTERNAL CONNECTION 

9.1 From circuit switched network 

B party is active and replies. 
A party in another 

network MBX-network 3-party 



DIALLED 
SIGNAL 
TO A 



' EXTCONREQ ' (1) 



COMMENTS : The procedure is completely identical to a 
ordinary connection. The only difference is 
that EXTCONREQ is used instead of CON**R. . 



EXTCONREQ (1) 


CONREA (2) 




Sender: EXT NET 


Sender: . 


B-PARTY 


Addressee: B-PARTY 


Addressee: 


EXT NET 


Traf State: OK 


Traf State: 


OK 


DIGITAL P: 0 


DIGITAL F: 


0 


EXTERN_F: 1 


EXTERN_F: 


0 


Line no. : Z 


Line no. : 


Z 


Conn. I.D. Y 


Conn. I.D. 





Ext.sub.no: A-party's number in 

external network, if known 



DISCON (3) 



Sender : B-Pi 

Addressee: EXT 

Traf State: OK 

DIGITAL F: 0 

EXTERN_F: 0 

Line no. : Z 

Conn. I.D. Y 
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9.2 To circuit switched network 




A-party MBX 


-network 


B-part in 
another network 



' EXTCONREQ ' ( 1 ) 



DIALLED 
SIGNAL 
TO A 



COMMENT : The procedure is completely identical to a 

ordinary connection. The only difference is that 
EXTCONREQ is used instead of CON**R. 



EXTCONREQ (1) 



Addressee: 
Traf State: 
DIGITAL F: 



DISCON (2) 

Sender : 
Addressee: 
Traf State: 
DIGITALJP: 
EXTERN_F: 
Line no . : 
Conn. I.D. 



A-PARTY 
EXT NET 



B-party's i 
in external network 
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10 CONNECTION TO GROUP 

10.1 Ordinary circuit switched connection to group 



MBX-network 



CONNEC- 
TION IN 
PROGRESS 




COMMENT : If the B-party accepts CONORD, CONREA shall not 
be sent. Neither may the B-party send DISCON on 
a connection that has been generated with 
CONORD. 



If there is no HOOK-OFF within 60 seconds after the 
reception of CONORD or if the B-party generates HOOK-ON 
during the connection, the B-part terminal shall return to 
the system channel without sending DISCON. More details of 
this are given in the link layer for mobile terminals. 

We do strongly recommend that, after reception of a 
CONORD, the terminal turns the loudspeaker on. 



CONREQ (1) 




CONORD (2) 




Sender: 


A— PARTY 


Sender : 


A-PARTY 


Addressee: 


B-PARTY 


Addressee: 


B-PARTY 


Traf State: 


OK 


Traf State: 


OK 


DIGITAL F: 


0 


DIGITAL F: 


0 


EXTERN F: 


0 


EXTERN_F: 


0 


Line no.: 


0 


Line no. : 


z 


Conn. I.D. 


X 


Conn. I.D. 


Y 
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DISCON (3) 




DISCON (4) 




Sender: 


A-PARTY 


Sender: 


A-PARTY 


Addressee: 


B-PARTY 


Addressee: 


B-PARTY 


Traf State: 


OK 


Traf State: 


OK 


DIGITAL F: 


0 


DIGITAL F: 


0 


EXTERN_F: 


0 


EXTERN_F: 


0 


Line no. : 


0 


Line no.: 


Z 


Conn. I.O. 


X 


Conn. I.D. 


Y 



NOTE 1 : If . a fixed terminal is B-party in a group a 
normal CONREQ is used to the fixed terminal. 

NOTE 2 : CONORD(2) is repeated continuously and may 

therefore appear also during the connection. 
CONORD(2) is repeated to give terminals the 
possibillity to connect to the group connection 
after- the group connection was made. This can 
be used if the terminal was busy when the group 
connection was made. 

NOTE 3: CONHEQ(l) can also be MPAK CONFAST. 
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11 ADDITIONAL CONNECTION 




11.1 Ordinary additional connection 



The A-party has one line for real time connection. The I 
party has one or more lines for real time' connection. 



The B party is active and replies. 
A-party MBX-network 
' ADDCONREQ '.(1) 



B-party 



DIALLED 
SIGNAL 
TO A 



' ADDCONREQ 1 (2) 



: The procedure is identical to a ordinary 
connection. The only difference is that • 
additional information 'S' follows the 
connection. 



(1) 

Sender : A-PARTY 

Addressee: B-PARTY 

Traf State: OR 

DIGITAL P: 0 

EXTERNj?: 0 

Line no.: 0 

Conn. I.D. Y 

Add. info: OPTIONAL=S 



ADDCONREQ (2) 

Sender : A-PARTY 

Addressee: B-PARTY 

Traf State: OK 

DIGITAL_F : 0 

EXTERN_P: 0 

Line no. : Z 

Conn. I.D. Y 

Add. info: S 



Exhibit 2, p. 396 



Cantel Mobitex~ 


[575: 1 1 

52/1056 - A 296 5171/2 Ue 


a.^.^ la.. Ik.fu 
1990-02-23 A |f4TS09B.2 



CONREA (3) 

Sender : B-PARTY 

Addressee: A- PARTY 

Traf State: OR 

DIGITAL_F: 0 

EXTERN_F: 0 

Line no.: Z 

Conn. I.D. y 



DISCON (4) 

Sender. B— PARTY 

Addressee: A-PARTY 

Traf State: OK 

DIGITAIi_F: 0 

EXTERN_F: 0 

Line no.: Z 

Conn. I.D. Y 



DISCON (5) 

Sender : A-PARTY 

Addressee: B-PARTY 

Traf State: OR . 

DIGITAL_F: 0 

EXTERN_F : 0 

Line no. s. 0 

Conn. I.D. Y 
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12 LINE TEST 






The network generates 'CLOOPON' and 'CLOOPOFF' according 
to the criteria and- with the structure given in Appendix 
A. 


Dialoque 12.1: 






Start of loop test. 

NET! 


■JORK 

1 CLOOPON 1 


3 


Dialoque 12.2: 






End of loop test. 




3 




<?0RK 1 
' CLOOPOFF 1 
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13 LOGIN 

The factor common to all dialogues for log-in is that the 
original packet ('LOGINREQ') is generated by the A-par.ty 
according to the criteria and with the structure stated in 
Appendix A. Reservation is stated for the respective 
dialogue. 



Dialogue 13.1: 
Login granted. 



A NETWORK 
•LOGINREQ' 1 • 

' LOGINGRA ' 2 
< 

The network generates 'LOGINGRA* according to the criteria 
and with the structure stated in Appendix A. 



Dialogue 13.2: 

Login refused by the network. 



The network generates * LOGINREF 1 according to the criteria 
and with the structure stated in Appendix A. 
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Dialoque 13.3: 




Login has not taken place 





A NETWORK 
' LOGINREQ ' 1 



'LOGINREQ* 2 

a) Log-in may not take place. Incorrect subscription 
number may have been given. 

1 LOGINREQ * 2 is returned with traffic state = ILLEGAL 

b) The network is overloaded. 

1 LOGINREQ' 2. is returned with traffic state = CONGEST 

c) A technical fault may have occured. 

'LOGINREQ* 2 is returned with traffic state = ERROR 



Exhibit 2, p. 400 



84 



Cartel Mobitex- 



52/1056 - A 296 5171/2 De 



1990-02-23 A 



The A-party generates ' LOGOUT * according to the criteria 
and with the structure stated in Appendix A. 



Dialogue 14.1: 
" Subscription initiates log-out. 



A NETWORK 
' LOGOUT ' 1 



Dialogue 14.2; 

Network initiates logout. 

The subscription has sent a LOGINREQ from a terminal but 
is still registered as logged-in to another terminal. The 
network will then send LOGOOTORD to the old terminal 
according to the criteria and with' the format stated in 
Appendix A. 

The personal subscription should immediately be deleted 
from the B-party's flexlist. 



NETWORK B 
' LOGOOTORD ' 1 



If the network has sent a LOGOOTORD and the old terminal 
did not receive it, the LOGOOTORD is repeated when the 
subscriber sends a message next time. 



Exhibit 2, p. 



Cantel Mobitex- 



52/1056 - A 296 5171/2 Ue 



15 ACTIVATION 

The A-party generates ' ACTIVE ' according to the criteria 
and with the format stated in Appendix A. 



Dialogue 15.1: 

Activation is approved and the mailbox is empty. 

A NETWORK 
1 ACTIVE ' 1 



Dialogue 15.2: 

Activation is approved and there are packets in the 
mailbox, both for the terminal and the personal 
subscription. 



MSG 1 and 2 are packets (MPAK) that has been stored in the 
network mailbox while the terminal has been inactive. 
Each packet sent out from the mailbox is delayed a certain 
time in order not to overload the terminal. 
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16 INACTIVATION 



The A party generates 'INACTIVE' according to the criteria 
and with the format stated in Appendix A. 



Dialogue 16.1: 
Inactivation. 



NETWORK 
' INACTIVE '1 
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17 DIE - LIVE 



The network generates 'DIE' and ' LIVE * according to the 
criteria and with the format stated in Appendix A. 

when the terminal receives 'DIE' it is not allowed to send 
any user traffic to the network, until a 'LIVE' has been 
received. Dser traffic is defined. as packets included in 
the packet classes; PSQBCOM, PSOSCOM and CSOBCOM. The 
terminal may send DTESEHV packets. 



Dialogue 17.1; 

The terminal may not send user traffic. 



'DIE' is stored in the network mailbox if the B-party is 
not active. The packet is sent out according to Dialogue 
15.2 when the B party is active again. 



Dialogue 17.2 ; 

The terminal may send packets again. 



'LIVE' is stored in the network mailbox if the B-party is 
not active. The packet is sent out according to dialogue 
15.2 when the B-party is active again. 
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' Dialogue 18.1; 

The network requests the terminal to send a ROAM packet. 

The network generates 'ROAMORD' according to the criteria 
and with the format stated in Appendix A. 



' ROAMORD 1 1 



The B-party generates 'ROAM' 2 according to the criteria 
and with the format stated in Appendix A. 



Dialogue 18.2: 

The A-party generates 'ROAM' spontaneously according to 
the criteria and with the format stated in Appendix A. A 
spontaneously generation of a ROAM packet is initiated 
from the roaming procedure described in the mobile 
terminal data link layer. 
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19 RE-DIRECTION OP EMERGENCY MESSAGES 



This is used when the emergency messages should be sent to 
the alternative emergency receiver. 

The A party generates 'VICESOSRX' according to the 
criteria and with the format stated in Appendix A. 



Dialogue 19.1: 

The re-direction is approved. 



'VICESOSRX' 1 



Dialogue 19.2: 

The ■VICESOSRX' is returned from the network. 



NETWORK 
' VICESOSRX * 1 



'VICESOSRX' 2 



a) Re-direction cannot/may not take place. 

' VICESOSRX ' 2 is returned with traffic state = ILLEGAL 

b) The network is overloaded. 

' VICESOSRX ' 2 is returned with traffic state = CONGEST 

c) A technical fault may have occurred. 

' VICESOSRX ' 2 is returned with traffic state = ERROR 
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20 CANCEL RE-DIRECTION OF EMERGENCY MESSAGES 



Dialogue 20.1: 

The re-direction is cancelled. 



Dialogue 20.2: 

The cancellation of the re-direction cannot/may not be 
accepted. 



•SOSRX' 2 is returned with traffic state = ILLEGAL 
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21 UPDATING GROOPLIST 



Dialogue 21.1; 



The network generates 'GROOPLIST' according to the 
criteria and with the format stated in Appendix A. 



NETWORK 

'GROOPLIST' 1 



•GROOPLIST' is stored in the network mailbox if the B 
party is not active. The packets are sent out according to 
dialogue 15.2 when the B party is active again. 
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22 UPDATING THE LIST OF PERSONAL SUBSCRIPTIONS 



Dialogue 22.1: 

The network generates 'FLEXREQ' according to the criteria 
and with the format stated in Appendix A. 



'FLEXLIST' 2 



'FLEXLIST' is generated according to the criteria and with' 
the format stated in Appendix A. 



Dialogue 22.2: 

The network generates 'FLEXLIST* according to the criteria 
and with the format stated in Appendix A. 

NETWORK B 
' FLEXLIST ' 1 

' FLEXLIST ' is stored in mailbox if the B party is not 
active. The packet is sent out according to dialogue 15.2 
when the B party is active again. 



Exhibit 2, p. 409 



Cantel Mobitex- 



52/1056 - A 296 5171/2 Ue 



1990-02-23 A MTS09B.2 



23 TECHNICAL INFORMATION 



Dialogue 23.lt 



The network generates * INFOREQ 1 according to the criteria 
and with the format stated in Appendix A. 



24 TIME INFORMATION 



Dialogue 24.1: 



The network generates 'TIME' according to the criteria and 
with the format stated in Appendix A. 
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25 UPDATING AREALIST 




Dialogue 25.1: 





The network generates 'AREALIST' according to the criteria 
and with the format stated in Appendix A. 



NETWORK 

'AREALIST" 1 



'AREALIST' is stored in the network mailbox if the B party 
is not active. The packets are sent out according to 
dialogue 15.2 when the B party is active again. 



26 ELECTRONIC SERIAL NUMBER CHECK 



Dialogue 26.1; 

The network generates ' ESNREQ * according to the criteria 
and with the format stated in Appendix A. 
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MOBITEX 

Network layer for terminals 
Appendix C. Logical description 



ABSTRACT 

This document contains the logical description for the network 
layer for mobile terminals connected to the MOBITEX system. 
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1.1 DATA FLOW DIAGRAM 

The data Elow diagram below shows the interaction between the 
network layer and the other two layers; the data link Layer and the 
application layer. 



| Application Layer { APP ) | 




.3 \ 


' 4 



NETWORK LAYER 





l ' 1 y 


r 2 


| Data Link Layer ( LINK ) 



Signals to/from Data Link Layer. 

-1- MPAK transmitted, MPAK_not_transmitted, MPAK_received, 
roaming, activation 

-2- MPAK_to_transmit, MPAK_to_retransmit, speech_on, speech_off , 
order_to_return MPAK, group_list_information, 
area_list_information 

Signals to/from Application Layer. 

-3- MPAK_received, returned_MPAK_with_code, die, live,- buffer_full 

-4- MPAK_to transmit, hook_6n, hook_off, power_off, 
manual mode on, MPAK to retransmit 
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1 . 2 TERMINOLOGY 
P_ / F_ 

input_signal 

wait_for_input_signal 
save_signal 



ignore_signal 
grouplist 
flexlist 
permanent_list 

g r oupl i s t_r ecei ved_f lag 

active_delay_power_up 
active_delay_lost_contact 
power_of f_ready 



In this logical description, all 
procedures starts with "P_" , and all 
functions with M F_". 

The network layer has an input queue. A 
signal from this input queue is called' 
"input_signal". 

The. network layer is waiting until' un 
input_signal is available. 

Restoring the signal into the queue. 
This is done when you expect a certain 
signal. By repeating input_signal and 
save_signal, you can search in the 
input queue for certain signals. All 
saved signals are available when an 
input signal fallows after an 
- input_signal. without any save_signal 
between. See chapter 'Queue handling'. 

No further handling of this signal, 
except that the signal should be 
'deleted. 

Area where group HAN are stored. This 
list should be stored also during power 
off. 

Area where personal subscription MAN 
are stored. This list should be stored 
also during power off. 

Total area to be continuously stored. 
In this area terminal MAN, serial 
number, group list, flexlist, die_state 
and live_state are stored. The checksum 
is calculated based on this list. 

Indication of a correct permanent list 
and that a MPAK: GROUPLIST is received 
or not. 

Activation delay concerning power-up 
and manual radio mode. See Rl-06. 

Activation delay concerning lost 
contact. See Rl-06. 

Flag to indicate that the network layer 
is ready to be closed. 
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raanual_mode Flag to indicate that the mobile 

station is in manual mode. 

buff er_full_f lag Indication of buffer full. 

emergency_flag Indication of an activated emergency. 

When application layer receive an 
emergency signal, this flag is raised. 
Now the network layer can handle the 
priority of emergency in the terminal. 
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1.2 SIGNALS 

MPAK_to_transmit 

MPAKjreceived 

MPAK_trarismitted 
MPAK_not_transmitted 
HPAK_t o_r et r ansmi t 

roaming 
activation 

speech_on 

speech_off 

order_to_return_MPAK 

group_list_information 
area_list_information 
returned MFAK_with code 



MPAK received from the application 
layer or MPAK to the data link layer to 
be transmitted. 

MPAK received by the data link layer or 
MPAK to be sent to the application 
layer. 

MPAK successfully transmitted by the 
data link layer. 

MPAK not transmitted by the data link 
layer . 

MPAK from the application layer to the 
data link layer to be retransmitted 
(special treatment in the data link • 
layer). 

Order to the network layer to send an 
MPAK: ROAM. 

Start activation timeout (after power- 
on or lost contact with base) given in 

Rl-06. 

Order to the data link layer to set 
mode speech_on. 

Order to the data iink layer to set 
mode speech_off. 

Order to the data link layer to stop 
sending an MPAK, and return the MPAK to 
the network layer. 

Group list information to the data link 
layer . 

Area list information to the data link 
layer . 

Returned MPAK with code information 
from the network layer. The code shows 
why the MPAK was returned. 
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hobk_on 


Hook_o 
layer. 


n signal from the application 




hook_off 


Hook off signal from the application 
'layer". 




die 


A signal informing that the network 
layer has received an MFAK:DIE. All 
user traffic is stopped and returned to 
the application layer. 




live 


A signal informing that the network 
laysr h3S rscsivsd* <in MPAKiLIVE* Ussr 
traffic from the application layer can 
be handled. 




bufferjEull 


Incoming and outgoing traffic from/ to 
the MOBITEX network is stopped. The 
network layer tries to send 
MPAK j INACTIVE. Application layer is 
informed. When the message buffer has 
space for at least 6 messages, 
according to specification Rl-09, the 
buffer_full_flag is reset and incoming 
and outgoing traffic is resumed. 




power_off 


The application layer wants to turn the 
network layer off.' The network layer 
tries to send an MPAK: INACTIVE. 




power_off_timeout 


Internal timeout to indicate that the 
network layer is ready to be turned 
off. 




iuanual_mode_on 


The application layer wants to turn 
over to manual radio mode. The network 
layer tries to send an MPAK: INACTIVE. 




raanual_mode_on_timeout 


Internal timeout to indicate that the 
network layer is ready to turn over to 
manual radio mode. 
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RETURNED HPAK WITH CODE 



CODE 



SENT ■ 
NOT_SENT 
NOT SE ' 



NOT_SENT_D IE 

NOT_SENT_BUFFER_FULL 

INCORRECT 

PERSONAL_HAN_EXI ST 
PERSONAL_HAN_NOT_EXIST 
FLEXLIST FULL 



This HPAK has been correctly sent by the 
data link layer. 

This HPAK has not been correctly sent by 
the data link layer. . 

This HPAK has not been' sent because of 
speech state in the network layer. 

This HPAK has not been sent because of die 
state in the network layer. 

This HPAK has not been sent because of 
buffier_full state in the network layer. 

Received HPAK from the application layer, 
do not have a correct format or is not 
allowed to be sent. 



The maximum number of HAN in the flexlist 
is exceeded. 



AJ32JISM 
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1 • 4 STATES 
idle 

die state 



sending_during_die 

linkjbusy 

sending_conreq 
stop_s ending 

wai t_f or_hook_of f _norraal 
wait_for_hook_off_fast 
wai t_for_hook_pff_g roup 

sending_conrea 

speech_normal 
speech_group 

sending_discon 



Idle state 

' A received MPAK:DIE has ordered the 
mobile to this state. No outgoing user 
traffic is allowed. A received 
MPAK:LIVE orders the mobile to idle 
state. 

Only MPAK of class DTESERV and 
HPAK:DISCON (CSUBCOM) can be sent 
during die_state. " 

The data link layer can only handle one 
packet at a time. In the present state, 
the data link layer is busy. 

The data link layer is busy sending 
speech request. 

The network layer has ordered the data 
link layer to stop sending present 
packet. The network layer is waiting 
until the data link layer is ready. 

A normal speech request is received and 
the network layer is waiting for 
response from the 'application layer. 

A fast speech request is received and 
the network layer is waiting for 
response from the application layer. 

A group speech request is received and 
the network layer is waiting for 
response from the application layer. 

The data link layer is busy sending a 
hook_off signal (MPAK:CONREA) . 

The network layer is in speech state. 

The network layer is in group speech 
state. 

The data link layer is busy sending a 
hook_on signal { MPAK : DISCON) . 
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1.5 STATE DIAGRAM 



STOP 




SENDING 




WAIT FOR 


SENDING 




CONREA 




HOOK OFF XXX 



SENDING 
DISCON 



WAIT_FOR_HOOK_OFF_XXX can be in three different states depending on 
the received speech request, as follows: 



STATE 

WAIT_FOR_HOOK_OFF_NORHAL 

WAIT_FOR_HOOK_OFF_FAST 
WAIT_FOR HOOK OFF GROUP 



WHEN RECEIVING 

CONREQ, ADDCONREQ, SOSCONREQ or 
EXTCONREQ 

CONFAST, ADDCONFAST or SOSCONFAST 
CONORD 
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1.6 QUEUE HANDLING 

input queue: 
2 , 



Input_signal: 

3 | 
2 | 



Save_signal: 



Input_signal 
3 I 



and save_signal: 



1 r 



Input_signal : 
4 I 

3 I " 



Input_signal : 



input_queue_pointer 



input_queue_pointer+l 
signal available for user 



input_queue_pointer+i 
save_input_queuejpointer 



input_queuejaointer+2 
save_input_queue_pointer+l 
sa ve_i npu t_queue_poi n t e r 

input_queue_pointer+3 
signal available for user 
save_input_queue_pointer+l 
save_input_queue_pointer 



input_queue_poi n t e r +1 
signal available for user 
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2 LOGICAL DESCRIPTION 






2.1 Start of program 






This program have two different modes, MOBITEX mode and MANUAL mode. 
In MANUAL mode, the network layer is stopped. 

When MOBITEX mode is activated from MANUAL mode the network layer 
should be restarted. 




NETWORK^LAXER 

P activation handling 
next_state =~idle 
emergency flag = FALSE 
IF permanent list is not correct THEN 
make MPAK BORN 

send MPAK_to_transmit to LINK 
next state =~link busy 
reset grouplist and flexlist 
set NOT grouplist received flag 
ENDIF 




LOOP 

IF manual mode THEN 

MOBITEX network layer inactivated 
activated = FALSE 
• handle manual mode 




wait for input signal 
IF- emergency flag THEN 
P look foF emergency 
ENDIF 

CASE signal 






WHEN MPAK to transmit from APP 

P_MPAK~FROM_APP 




WHEN MPAK to retransmit from APP 
P_MPAK~TOJlETRANSMIT 




WHEN MPAK received from LINK 
P_REC_MPAK_FROM_L INK 




WHEN MPAK transmitted from LINK 
P_MPAK_TRANSMITTED 




WHEN MPAK not transmitted from LINK 
P_MPAK~NOT~TRANSMITTED 




WHEN hook on from APP 
P_HOOK~ON_handling 

WHEN hook off from APP 
P_HOOK~OFF_handling 

WHEN hook_off_timeout 
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P_t imeout_handl ing 

WHEN roaming from LINK 
P_roaming_handling 

WHEN activation from LINK 
P_activation_handling_link 

WHEN activation timeout 

P_activationJ:imeout_handling 

WHEN power_off from APP 
P_powe r_of f _handl i ng 

WHEN manual_mode_on 

P_manual_raode~on_handling 

WHEN power_off timeout 
set power_of"f_ready 

WHEN manualjnode. on_timeout 
set raanual_moa"e 

WHEN buffer_full 

P_buffer~full_handling 



END_NETWORK LAYER 
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2.1.1 P_LOOK_FORJEMERGENC¥ 




P look for esifirgsncy 




emergency_signal = FALSE 




WHILE NOT emergency_signal THEN 




CASE - MFAR ■ type 




WHEN SOS , SOS INFO , SOSACK , SO 
eraergency_signal = TR 


SCONREQ , SOSCONFAST 
OE 


WHEN OTHERWISE 

save_signal 
input signal 

ENDCASE 




ENDWHILE 
END_P_look_for_emergency 
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2 . 2 P_MPAK_FROM_APP 



P_KPAK_FROH_APP 

IP NOT buffer_full_flag : 
CASE next_state"~ 



I idle 

CASE HP AK. class 
WHEN PSUBCOM,PSOSCOM 
P_checlc format 
IP format = true THEN 

send MPAK_to_transmit to LINK 
next_state = LINKJBUSY 
ELSE 

send returned_MPAK_with_code: INCORRECT to APP 
ENDIP ~ 
WHEN CSOBCOM 

P_check_forraat 

IF format = true THEN 

P_check_and_send_CSOBCOM 

send returned_MPAK_with_code: INCORRECT to APP 
ENDIP ~ 
WHEN DTESERV 

P_check_format 

XP format = true THEN 

P_check_and_send_DTESERV 
ELSE - ~ ~ 

send returned MPAK_with_code: INCORRECT to APP 



ENDCASE 
I die_state 

IF MPAK. class = DTESERV THEN 
P_check_format 
IP format = true THEN 

P check and send DTESERV 
ELSE" 

send returned MPAK with code : INCORRECT to APP 
ENDIP ~ 
ELSE 

send r eturned_MPAK_with_code : NOT_SENT_DIE 
ENDIP 

I wai t_f or_hook_of f _normal , 
wait_f or_hook_of f _f ast , 
wait_for hook off_group 
IF MPAK. class = CSOBCOM THEN 
P_check_f o rraat 
IF format = true THEN 
CASE MPAK. type 
WHEN CONREA 

P_hook_off_handling 
WHEN DISCON 

P hook_on_handling 
WHEN~OTHERWI SE 
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send returned_MPAK_with_code :NOT_SENT_SPEECH 




WUWUB 

send returned MPAK 
ENDIF 


_with_Code: INCORRECT to APP 




IF MPAK. Class = PSOSCOM THEN 

save signal 
make hook on signal 
P HOOK ON handling 
ELSE ~ 

send returned MPAK with code: NOT SENT SPEECH to APP 
ENDIF 
ENDIF 

WHEN sending conr eg, sending conrea,speech_normal,speech_group 
IF MPAK. class = CSUBCOM THEN 
P check_format 
IF format .= true THEN 
CASE MPAK. type 
WHEN DISCON 

P^ook^n^handling . 
WHEN OTHERWISE 

"send returned MPAK with coderNOT SENT SPEECH 




ENDCASE 
ELSE 

send returned MPAKjwith_code: INCORRECT to APP 
ENDIF 




ELSE 

IF MPAK. class = PSOSCOM THEN . 
CASE next state 

WHEN sending _conreq,sending_conrea 
save signal 

send order to return_MPAK to LINK 

next state = stop sending 
WHEN speech normal, speech_group 

save_signal 

make"~hook on signal 

P HOOK ON~handling 
ENDCASE 




ELSE 

send returned MPAK with coderNOT SENT SPEECH 
ENDIF 




ENDIF 
WHEN OTHERWISE 

save signal 
ENDCASE 






ELSE 

CASE MPAK. class 
WHEN PSOBCOM, PSOSCOM 
P check- format 
IF format = true THEN 

send MPAK to transmit to LINK 
next_state = LINK_BUSY 




send returned_MPAK_with_code: INCORRECT to APP 
ENDIF 
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WHEN OTHERWISE 

send t etur ned_MPAK_wi t*i_code : NOT_SENT_BOFFER_FULL 
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2.2.1 F_CHECK_FORMAT 






F_check_format 






This routine checks and completes the format of this MPAK to be 

correct according to Rl-09 Appendix A. 

A correct MPAK will be returned with format = TRUE. 

An incorrect MPAK will be returned with format = FALSE. 




END_F_checfc_format 






2.2.2 P_CHECK_AND_SEND_DTESERV 






P check and send DTESERV 
CASE MPAK. type" 






WHEN LOGINREQ 

IF MPAK. type dependent in our flexlist THEN 

send returned MPAK with code : PERSONAL_MAN_EXIST to APP 




ELSE 

IF more space in our flexlist 
MPAK. sender = MCU MAN 
send MPAK to transmit to LINK 
next_state =~LINK_BUSY 




send returned MPAK with code : FLEXLIST_FULL 
ENDIF 

endif' 




WHEN VICESOSRX r SOSRX 

IF MPAK. sender in our flexlist THEN 
send MPAK to transmit to LINK 
next state =~LINK BUSY 




send returned_MPAK_with_ 

ENDIF 


COde: PERSONAL MAN NOT EXIST to 
APP 




WHEN LOGOUT 

remove MPAK. sender from our flexlist 
MPAK. type dependent = MCU MAN 
send MPAK~to transmit to LINK 
next_state «~LINK_BUSY 




WHEN ACTIVE, INACTIVE 

send MPAK to transmit to LINK 
next state ■= LINK BUSY 






send returned_MPAK_with_code: INCORRECT to APP 




ENDCASE 
END_P_check_and_sendJDTESERV 





A29J51S13 
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2.2.3 P_CHECK_AND_SEND_CSUBCOM 

P_check_and_send CSOBCOM 
CASE MPAK. type 

WHEN CONHEQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONFAST , SOSCONFAST 

MPAK.line = 0 

MPAK. connection identity ~ next MPAK.connection_identity 
SPEECH_REG.part~here = MPAK. sender 
SPEECH_REG.other_part = MPAK. addressee 
SPEECH REG. line = MPAK.line 

SPEECH~REG.conn_id = MPAK.connection_identity 
send MPAK_to_transmit to LINK 
next_state =~sending_conreq 

WHEN DISCON 

send MPAK DISCON with 

MPAK. sender = SPEECH_REG.part_here 
. . MPAK. addressee = SPEECH REG.other_part 
MPAK.line = SPEECH_REG .Tine 

MPAK.connection_identity = SPEECH_REG . conn_id 
send MPAK to transmit to LINK 
next_state '"sending discon 



ignore_signal 



ENDCASE 



: and 5 
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2.3 P_MPAK_TO_RETBANSMIT 






PJMPAK_to_retransmit 






CASE next state 
WHEN idle 

CASH MPAK. class 
WHEN PSUBCOK, PSOSCOM 
P_check_f ormat 
IP format ■ true THEN 

send MPAK to retransmit to LINK 
next state =~LINK BUS* 
ELSE 




send returned MPAK with code : INCORRECT to APP 

ENDIF ~ 
WHEN OTHERWISE 

send returned MPAK with code : INCORRECT to APP 
ENDCASE . ~ 




WHEN die state 

send returned MPAK with code: NOT -SENT DIE 
WHEN wait_for_hook~off normal, ~" 
wait_f or_hook_of f fast r 
wait~far hook aff group 
IF MPAK . class = PSOSCOM THEN 
save signal 
make hook on signal 
P_HOOK_ON_handling 




^send'returned_MPAK_with_code:NOT_SENT_SPEECH to APP 




WHEN sending conreq, sending conrea, speech normal, speech group 
IP MPAK. class = PSOSCOM THEN 
CASE next^state 

WHEN sending conreq, sending conrea 
save_signal 

send order to return' MPAK to LINK 

next_state = stop sending 
WHEN speech_normal, speech group 

save_signal 

raake~hook on signal 

P HOOK ON~handling 
ENDCASE ~ ~ 




ELSE 

send returned MPAK with code: NOT SENT SPEECH 
END IP ~ ~ 
WHEN OTHERWISE 

save_signal 
ENDCASE ~ 
END_P_MPAK_to_retransmit 


3,Ukm 







A 232 SUM 
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2 . 4 P_REC_MPAK_FROM_L INK 




P_HEC_HPAK_FROM_L INK 





activated = TRUE 
CASE MPAK. class 
WHEN PSUBCOM.PSOSCOM 

IP F^get^jrecjnan = MCO_MAN or in flexlist or in grouplist THEN 
send MPAK received to APP 

ELSE 

P_unknown handling normal 

ENDIP ~ 
WHEN CSUBCOM 

P_REC_MPAK_CSUBCOM FROM LINK 
WHEN DTESERV 

IP F_get_rec_man = MCU MAN or in flexlist or in grouplist THEN 
CASE MPAK. state . ~ 
WHEN ak,from_mail 

P_REC_MPAK_DTESERV_FROM LINK_NORMAL 

WHEN OTHERWISE 

CASE MPAK. type 

WHEN • LOGINREQ,SOSRX r VICESOSRX 

send MPAK_received to APP 
WHEN OTHERWISE 
ignore signal 
ENOCASE 
ENDCASE 
ELSE 

P_unknown handling normal 
ENDIF 
ENOCASE 
END_P_REC_MPAK_FROM_LINK 



2.4.1 P_UNKNOWN_HANDL I NG_NORMAL 



P_unknown_handling normal 

CASE next state 

WHEN idle" 

set MPAK . UNKNOWN_F = 1 

send MPAK_to transmit to LINK 

next_state =~link busy 

WHEN die_state 

set MPAK. UNKNOWN F = 1 

send MPAK_to_transmit to LINK 

next state = sending_during die 

WHEN OTHERWISE • ~ 

save_signal 

ENDCASE 

EMD_P_junknown_handling normal 
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2.4.2 P_REC_MPAK_DTESERV_FROH_LINK_NORMAL 

PJREC_MPAK_DTESERV PROM LINK NORMAL 
CASE MPAK . type ~ ~ 
WHEN LOGINGRA 

Add personal subscription MAN to the flexlist 

send MPAK received to APP 
WHEN LOGINREF 

send MPAK_received to APP 
WHEN LOGODTORD 

remove personal subscription MAN from the flexlist 

send MPAK_received to APP 
WHEN DIE 

' IP next_state - idle or die_state THEN 
next_state = die state 
send die to APP ~ 

save signal 
. END ~ 

WHEN LIVE ._ 

IP next_state = idle or die state THEN 
next state = idle ~ 
send~"live to APP 
ELSE 

save_signal 

END 

WHEN GROOPLIST 

replace grouplist 

set grouplist_received flag 

send MPAK_received to APP 

send group list information to data link layer 
WHEN AREALIST 

send area list information to data link layer 
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WHEN ROAMORD / FLEXREQ , INFOREQ , ESNREQ 

IF next_state = idle pr die scate THEN 
CASE MP AK. type 

WHEN ROAMORD make MPAK.type ROAM 
WHEN FLEXREQ make MPAK.type FLEXLIST 
WHEN INFOREQ make MPAK.type INFO 

I ESNREQ make MPAK.type ESNINFO 



send MPAK_to transmit to LINK 
CASE next_state 

WHEN idle next state = link busy 

WHEN die_state next~state = sendTng_during_die 



ELSE 

save signal 

ENDIF " 
WHEN FLEXLIST 

replace flexlist. 

send MPAK received to APP 
.WHEN TIME ~ 

send MPAK_received to APP 
WHEN OTHERWISE 

ignore_signal 
ENDCASE MPAK 
>_P_REC_MPAK_DTESERV_FROM_LINK_NORMAL 
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2.4.2.1 F_GET_REC_MAN 



F_get_rec_man 

CASE MPAK. state 
WHEN ok,from_mail 

F_get_rec_man = MPAK. addressee 
WHEN OTHERWISE 

P_get_rec_raan = MPAK. sender 
ENDCASE MPAK. state 
END_P_get_rec_man 



2.4.3 P_REC_MPAK_CSOBCOM_FROM_LINK 



P_REC_MPAK_CSOBCOM_FROM_L1NK 
CASE next_state ~ 
WHEN idle~ 

P_REC_MPAK CSUBCOM_FROM_LINK_IDLE 
WHiM link_busy, sending during~die,stop sending 

save signal ~ ~ 
WHEN die_state 

P REC_MPAK_CSUBCOM_FROM_LINK_DIE 
WHEN wart_for_hook_off_normal, 
wait_for_hook_off_fast, 
wait_for_haok_off_group 

P_REC_MPAK_CSUBCOM FROM_LINK_WAIT 
WHEN speech normal, speecE_group 

P_REC~MPAK CSUBCOM FROM LINK_SPEECH 
WHEN sending_conreq ~ 

CASE MPAK. type 

WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONFAST , SOSCONFAST , CONORD 
save_signal 

send order_to_return_MPAK to LINK 
next state = stop sending 
WHEN OTHERWISE 

ignore signal 
ENDCASE MPAK 
WHEN sending_conrea 

IF MPAK. type DISCON THEN 
send MPAK_received to APP 
send order_to_return_MPAK to LINK 
next state = stop sending 
ELSE 

ignore_signal 

send order_to_return_MPAK to LINK 

next state~= stop sending 
ENDIF ~ 
WHEN sending discon 
save_sTgnal 

send order_to_return_MPAK to LINK 
next_state = stop sending 



END_P_REC_MPAK_CSDBCOM_FROM_LINK 
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P_REC_MPAK_CSUBCOM_FROM_LINK IDLE 
CASE MPAK . type ~ 
WHEN CONREQ , ADDCONREQ , SOSCONREQ/ EXTCONHEQ 
CASE MPAK. state 
WHEN Ok 

IP F_get_rec_man = MCU_MAN or in flexlist 
start 60 second timer for hook off 
SPEECH_REG.part_here = MPAK. addressee 
SPEECH_REG.other_part = MPAK. sender 
SPEECH_REG .line = MPAK. line 

SPEECH_REG.conn_id = MPAK.connection_identity 
send MPAK_received to APP 
next_state = wait_for hook_of f_normal 
ELSE 

P_unknown .handling_csubcom 
ENDIP 
WHEN OTHERWISE 

send speech_off to LINK 
ENDCASE MPAK. state 
WHEN CONFAST , ADDCONFAST , SOSCONFAST 
CASE MPAK. state 
WHEN ok 

IF F_get_rec_man = MCD_MAN or in flexlist 
start 10 second timer for hook off 
SPEECH_REG.part_here = MPAK. addressee 
SPEECH_REG. other _Dart = MPAK. sender 
SPEECH_REG . line =" MPAK. line 

SPEECH_REG.conn_id = MPAK.connection_identity 
send MPAK_received to APP 
next_state = wait_for_hook_of f_fast 
send~speech on to LINK 
ELSE 

P unknown handling csubcom 
ENDIF 
WHEN OTHERWISE 

send speech_off to LINK 
ENDCASE MPAK. state 
WHEN CONORD 

CASE MPAK. state 
WHEN ok 

IF F_get rec_raan in grouplist 

start~60 second timer for hook off 
send MPAK_received to APP 
next state = wait_£or_hook_of f_group 
. send~speech_on to LINK 

ELSE 

send speech off to LINK 

E NDIF 
WHEN OTHERWISE 

send speech off to LINK 
ENDCASE MPAK. state 
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WHEN OTHERWISE 

send speech off to LINK 
ENDCASH MPAK 
END_P_REC_HPAK_CSnBCOM_FROMJC.INK_IDLE 



2.4.3.2 P_UNKNOWN_HANDLI NG_.CSUBCOM 



P_unknown handling csubcom 
send~speech_on to LINK 
make MPAK DISCON with 

MPAK. sender = received_MPAK. addressee 
MPAK. addressee = received_MPAK. sender 
MPAK. line = received_MPAK.line 
MPAK.connection_identity = 

received MPAK. connection identity 
MPAK . UNKNOWN_F= 1 ™ 
send MFAK_to_transmit to LINK 
next_state = ..sending^discon 
END_Pjunknown_handling_csubcom 



2.4.3.3 P_REC_MPAK_CSUBCOM_FROM_LINK_DIE 



P_REC_MPAK CSUBCOM FROM LINK DIE 
. CASE MPAK .type ~ 
WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONFAST , SOSCONFAST 
CASE MPAK. state 
WHEN Ok 

send speech_on to LINK 
make MPAK DISCON with 

MPAK. sender = received_MPAK. addressee 
MPAK. addressee = received_MPAK. sender 
MPAK. line = rec'eived_MPAK7line 
MPAK.connection_identity = 

received MPAK. connection identity 
IF F_get_rec man = MCU MAN~or in flexlist 

send MPAK~to transmit to LINK 
ELSE ~ ~ 

set DNKNOWN_F = 1 in MPAK DISCON 
send MPAK to_transmit to LINK 
ENDIF 

next_state = sending_during_die 
WHEN- OTHERWISE 

•send speech off to LINK 
ENDCASE MPAK. state 
WHEN OTHERWISE 

send speech off to LINK 
END_P_REC_MPAK_CSDBCOM~FROM_LINK_DIE 
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P_REC_MPAK_CSOBCOM FROM LINK WAIT 
CASE MP AK. type ~ 
WHEN DISCON 

reset hook_off timeout 

send speech off to LINK 

send MPAK_received to APP 

next_state = idle 
WHEN CONORD 

ignore signal 

IF next_state < > wait_for_hook_of fjgroiip • 
reset hook. of f timeout 
send speech_off to LINK 
next state = idle 
make MPAK DISCON 
send MPAK received to APP 

END IF 



END_P_REC_MPAK_CS0BC0M_FROM LINK WAIT 
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P_REC MPAK CSUBCOM FROM LINK SPEECH 



P_REC_MPAK CSUBCOM FROM LINK SPEECH 
CASE MPAK. type ~ 
WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONF AS T , SO S CO N FAS T 
CASE MPAK. state 

WHEN no_transfer, illegal, congest, error , busy 

send speech_off to LINK 

send MPAK received to APP 

next_state = idle 
WHEN OTHERWISE 

ignore signal 

make MPAK DISCON 

send MPAKjreceived to APP 

send speech_off to LINK 

next_state- = idle 
ENDCASE MPAK. state 
WHEN DISCON 

send MPAK received to APP 

send speech_off to LINK 

next state = idle 
WHEN CONORD 

ignore_signal 

IF next_state < > speech_group THEN ■ 
make MPAK DISCON ~ 
send MPAK_received to APP 
send speech_off to LINK 
next_state = idle 

END IF 
WHEN OTHERWISE 

ignore signal 
make MPAK DISCON 
send MPAK_received to APP 
send speech off to LINK 
next_state = idle 



END_P_REC_MPAK CSUBCOM FROM LINK SPEECH 
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2.5 P_MP AK_TRANSMI TTED 

F_MPAK_TRANSMITTED 
activated = TRUE 
CASE MPAK. class 
WHEN PSUBCOM,?SOSCOM,DTESERV 
CASE next_state 
WHEN linkjausy 

next_state = idle 
WHEN sending during die 

next_state = die^state 
ENDCASE 

IP MPAK. UNKNOWN F = 0 THEN 

IP MPAK. class" = DTESERV THEN 
CASE MPAK. type 

WHEN LOGINREQ,SOSRX,VICESOSRX 

send returned_MPAK_with_code:SENT to APP 
WHEN INACT-IVE 

IP power_off THEN 

set power off ready 

ENDIP 

IF manual_mode_on received THEN 
set manual mode 



send returned_MPAK_with_code:SENT to APP 
IP (MPAK. class = PSOBCOM) AND {buff er_full_f lag) 
• make MPAK INACTIVE 
send MPAK to_transmit to LINK 
next_state = link busy 
ENDIP MPAK. class 
ENDIP MPAK. class 
ENDIP MPAK . UNKNOWN F 
I CSUBCOM 

CASE MPAK . type 

WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 

CONFAST , ADDCONFAS T , SOSCONFAST 

send speech on to LINK 

send returned_MPAK_with_code:SENT to APP 

next state = speech normal 
WHEN CONREA 

send speech on to LINK 

send returned MPAK with code: SENT to APP 



send speech off to LINK 
send returned MPAK_with_code : SENT t o AP P 
IF next_state~= sending_during_die THEN 
next state = die state 



next state =• idle 



ENDCASE MPAK 
ENDCASE MPAK. Class 
END_P_MPAK TRANSMITTED 
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2 . 6 P_MPAK_NOT_TRANSMITTED 




P MPAK HOT TRANSMITTED 




CASE MPAK. class 




WHEN PSOBCOM,PSOSCOM,DTESERV 




CASE next state 




WHEN link_busy 




next state = idle 




WHEN sending during die 




next state « die state . 


WHEN stop_sending 




next state = idle 




ENDCASE ~ 




IF MPAK. UNKNOWN F = 0 TH 


EN 


IE MPAK. class = DTESE 


RV THEN 


CASE MPAK. type 




WHEN LOGINREQ,S0SRX,VICES0SRX 


send returned MPAK with code: NOT SENT to APP 


WHEN INACTIVE 




IP power off 


THEN 


set power off ready 


ENDIP 




IP manual mo 


de on received THEN 


set manual mode 


ENDIP 




ENDCASE 

ELSE 




send returned MPAK with coderNOT SENT to APP 


ENDIP MPAK. class 




ENDIP MPAK. UNKNOWN F 




WHEN CSOBCOM 




CASE MPAK . type 




WHEN CONREQ , ADDCONREQ , SOSCONR 


EQ,EXTCONREQ, 


CONFAST , ADDCONFAST , SOSCONFAST 


IP next state = sending conreq THEN 


send speech off to LINK 


next state ■ idle 

uiium nmmcTi 




send speech off to LINK 


next state = idle 




WHEN DISCON 




send speech off to LINK 


IP next state = sending during die THEN 


next_state = die_state 
ELSE "" 


next state = idle 


ENDIP 




ENDCASE MPAK 




send returned MPAK with code: NOT SENT to APP 


ENDCASE MPAK. class 




END_P_MP AK_NOT_TRANSMI TTED 









A.J31SUM 
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2.7 P_HOOK_ON_HANDLING 



P_HOOK_ON_handling 
CASE next_state 

WHEN wait for_hook_off_normal, 
wa i t~f o r_hook_o f f _f ast , 
wait~forJiook~off_grOup 

~ reset hook_o£f timeout 
P_t imeout_ha nd 1 i ng 

WHEN sending_conreq,sending_conrea 
save_signal 

send order_to_return_MPAK to LINK 
next_state = stop_sending 

WHEN speech_normal 

make MPAK .DISCON with 

MP AK. sender = SPEECH_REG.part_here 
MPAK. addressee = SPEECH_REG.other_part 

MPAK. line = SPEECH_REG, line 

MPAK.connection_identity = SPEECH_REG . conn_id 
send MPAK_to_transmit - to LINK 
next_state =~"sending_discon 

WHEN speech_group 

""send speech_off to LINK 
next_state = idle 

WHEN idle 

IF line connection request received THEN 
make MPAK DISCON with 

MPAK. sender = SPEECH_REG.part_here 
MPAK. addressee = SPEECH REG.otherjpart 
MPAK. line = SPEECH_REG . Tine 

MPAK.connectionj.dentity = SPEECH_REG.conn_id 
send MPAK_to_transmi't to LINK 
next state = sending_discon 
ELSE 

ignore signal 
ENDIF 
WHEN OTHERWISE 

ignore_signal 
ENDCASE next_state~ 
END P HOOK ON handling 
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2.8 PJDIMEOUT_HANDLING 

P_t imeou t_handl ing 
CASE next_state 

WHEN wait_f or_hook_of f_normal , waifc_f or_hook_of f_f ast 
send speech_on ta LINK ~ 
make MPAK DISCON with 

MPAK. sender = SPEECHJREG.partjiere 
MPAK. addressee = SPEECH_R£G.other_part 
MPAK. line = SPEECH_REG. line 

MPAK. connect ion_identity = SPEECH_REG.conn_id 
send MPAK_to_transrait to LINK 
next_stati" =~sending_discon 

WHEN wait_for_hook_pff_group 
send speech_off to LINK 
next_state = idle 

WHEN OTHERWISE 

ignore_signal 
ENDCASE next_state 
END_P_t imeou tjiandli ng 



2.9 P_HOOK_OFF_HANDLING 



P_HOOK_OFFJiandling 
CASE next_state 
WHEN wait_for hook_ofE normal 
reset hook off timeout 
make MPAK CONREA with 

MPAK. sender = SPEECH_REG . par t_he r e 
MPAK. addressee = SPEECH_REG.other_part 
MPAK. line = SPEECH_REG . line 

MPAK.connection_identity = SPEECH_REG.conn_id 
send MPAK_to transmit to LINK 
next_state =~sending_conrea 

WHEN wait for_hook off fast 
r_esi"t hook_of"f timeout 
next_state = speech_normal 

WHEN wait_for_hook_off group 
reset hook_off timeout 
next_state = speech_group 

WHEN OTHERWISE 

ignore_signal 
IE next state 
END_P_HOOK_OFF_handling 
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2.10 P_ROAMING HANDLING 



P_roaming_handling 

IP next_state « idle or die_state 
IP grouplist received flag THE 

make MPAK ROAM ~ 
.ELSE 

make MPAK BORN 
END IF 

send MPAK_to transmit to LINK 
CASE next state 
WHEN idle - 



next_state = sending_during_die 



save signal 

IDIF ~ 

ID_P_roaming_handling 
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2 . 11 P_ACTIVATION_HANDLING 




P activation handling 

IP HOT buffer full flag THEN 
activated = — FALSE 

start activation timer with «active_delay_power_pn' 
ENDIF 

END_P_activation_handling 


2 . 12 P_ACTIVATION_HANDLING_LINK 




P activation handling link 

IP NOT buffer full flag THEN 
activated = FALSE - 

start activation timer with 'active delay lost_contact' 


END_P_act iva t ionjiandli ngJLink 




2.13 P_ACTIVATION_TIMEOOT_HANDLING 


P activation timeout handling 

IP next state =-iale or die state THEN 
IP NOT activated THEN 
make MPAK ACTIVE 
. send MPAK to transmit to LINK 
CASE next state 
WHEN idle" 

' next state = link busy 
WHEN die_state 

next state = sending during die 
ENDCASE 


ELSE 

save signal 
ENDIF ~ 
END_P_activation_timeout_handling 
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2.14 P_POWER_OFF HANDLING 



P_power_o£f_handling 
power_off received 
start~power_o£f timer 
CASE next state 
WHEN idle- 
make- MPAK INACTIVE 

send MPAK_to transmit to LINK 

next_state =~link busy 
WHEN die_state _ 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 

next_state = sending during_die 
WHEN speech_normal,speech_group,wait_£or_hook_off_normal, 
wait_£or_hook_off_fast,wait_for_hook_off_groITp, 
sendTng_conrea, sending jdiscon,sending_conreq 

disconnect the speech (according to current state) 

make MPAK INACTIVE 

send MPAK_to_transmit to. LINK 

next_state = link busy 
WHEN OTHERWISE ' 

save signal 
ENDCASE 
END_P jpower_of f _handl i ng 



2.15 P MANUAL MODE ON HANDLING 



Pjnanual_mode_on_handling 
manual_mode_on received 
start raanual_mode_on_timer 
CASE next state ~ ~ 
WHEN idle" 

make MPAK INACTIVE 

send MPAK_to transmit to LINK 

next_state =~link_busy 
WHEN die state 

make MPAK INACTIVE 

send MPAK_to_t ransrai t to LINK 

next_state = sending_during_die 
WHEN speech normal, speech group, wait f or_hook_o£f _norraal , 
wait_f or_hook_of f_f ait , wait_for"hook_off "group, 
sending_conr ea , sending_discon , sending_conr eq 

disconnect the speech (according to current state) 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 
next_.state ="link_busy 



save signal 
MDCASE 

»_P_manual_mode_on_handling 
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2.16 P BUFFER FULL HANDLING 



P_buf f er_f ulljtiandling 
CASE next_state 
WHEN idle 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 

next_state =~link_busy 
WHEN die state 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 

next_state = sending_during_die 
WHEN speech_normal,speech_^group,wait for hook_of f_normal, 
wait for hook off_f ast,wait_for~hook_of f_group, 
sendTng_conrea,sending_discon, sending conreq 

disconnect the speech (according to current state) 

make MPAK INACTIVE •• 

send MPAK_to_transmit to LINK 

next_state = link busy 



save_signal 



send buffer full to APP 
set buffer_iull_flag 

END_P_buffer_full_handling 
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3 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Below are the reference designations listed. 

Reference Section 

Rl-01 •■ Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 — Terminology 

Rl-05 References 

Rl-06. Network operator information 

Rl-08 Application layer 

Rl-09 ' Network layer 

Rl-ll Interface requirements, fixed terminals 

Rl-1'2 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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MOBITEX 

HDLC interface 
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ABSTRACT 



This document is a specification of the interface for a 
fixed terminal with HDLC interface, connected to the 
MOBITEX network. 
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1 INTRODUCTION 



1 . 1 GENERAL 

The designation "terminal" for a fixed terminal in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions and secondary station in HDLC. 

CCITT recommendation X.21 bis is used at the physical 
layer and HDLC is used at the link layer. The network 
layer consists -of MPAK's according to reference Rl-09. 
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2 PHYSICAL LAYER 



Connection is in accordance with CCITT recommendation X.21 
bis. 



2.2 B URATE 



For information about permitted bitrate transmission 
rates, please refer to reference Rl-06. 
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3 LINK LAYER 



3 . 1 GENERAL 



The design of the link layer follows ISO standards "High 
level data link control" {HDLC) • See ISO 3309-1984, ISO 
4335-1984 and ISO 7809-1984 for reference. 



3.2 SUB-SET OP HDLC 

HDLC is a comprehensive catalogue of standards for link 
control. The ONC 12 class, i.e. "Unbalanced operation, 
normal response mode" with added test function, of 
procedure is used for the link layer. 

The MOBITEX network is the primary station and the fixed 
terminal is the secondary station. 



3.2.1 Clarification 

3.2.1.1 Commands and responses 

The following commands and responses are obtained with the 
above class: 



Command from 
. network 


Response from 
fixed terminal 


I 

RR 


I 

RR 


RNR 
SNRM 


RNR 
UA 


DISC 


DM 




FRMR 


TEST 


TEST 



A frame can be up to 566 octets including start and stop 
flag. This will allow 560 octets in an information field 
in an I frame. 
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3.2.1.3 ' The use of the address field 

The address field comprises one octet. The address in the 
address field shall be adjustable. The factory set address 
shall be 11000000 (bit 1...8). 

Address 11111111 is defined as the all-station address and 
thus all receiving data stations shall accept and action 
the associated frame. If the P bit is set in such a frame, 
the terminal shall reply with its own address as reply 
address. 



3.2.1.4 FRMR responses 

The information field in an FRMR response shall be padded 
with zeros so .the length will be 3 octets. 

3.2.1.5 TEST -frames 

. TEST frames can contain an information field. The maximum 
length of that field is the same as' for I-frames. 

TEST frames can be' transmitted and received both in NRM 
and ndm. 
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3.3 OPERATING MODES FOR THE LINK LAYER 

The link layer shall be able to assume the following 
modes : 

o Normal resanse mode (NRM) according to ISO 4335 item 
5.1.1. 

o Normal disconnected mode (NDH) according to ISO 4335' 
items 5.2 and 5.2.1. 

A terminal's capacity in NDH is limited to: 

- accepting the mode setting commands (SNRM or DISC) 

- accepting and responding to a test command 

- transmitting DM or TEST at a respond opportunity 

A terminal- may only -change - to NRM from NDM by accepting an 
SNRM command from the network. 

A terminal can change from NRM to NDM by accepting a DISC 
command from the network or through manual restart of the 
link control. NDM shall be the initial mode when power is 
switched on or when restarting the terminal. 
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3.4 CONNECTION AND DISCONNECTION PROCEDURE 

The link is connected in accordance with ISO 7809 item 
3.4.1.1. The network transmits SNRM to the terminal. If 
there is no reply, the SNRM is retransmitted until an UA 
reply is received. 

Normal disconnection of the link is in accordance with ISO 
7808, item 3.4.1.2. If there is no reply from the 
terminal, DISC is retransmitted. This is repeated no more 
than 10 times or until an DA reply is. received. The link 
is then assumed to be disconnected and the connection at 
the lower level can be broken. 

If there are no frames to send, the link layer shall send 
flags cotitinuosly as soon as the physical layer is in data 
transmission mode. 



3.5 TIME-OUT 

When the terminal receives a correct frame with the P bit 
set to "1" (one), the reply shall commence within 50 ms. 
The time is calculated from when the last bit of the 
command's closing flag is received until the first bit of 
the response is transmitted. 

If several frames are transmitted in sequence, the time 
between them shall not exceed 50 ms. This time is 
calculated from the last bit of a frame's closing flag to 
the first bit of the next frame's opening flag. 

The terminal has no time-out function for recovery in the 
event of a link fault. The terminal however may have time- 
out function to inform the operator about a link fault. 
The time-out may not be less than 45s in NRM and 120 s in 
NDR. 



3.6 RECOVERY FROM FADXT CONDITION 

All recovery from a fault condition is carried out by the 
network. The terminal is first ordered to NDM and then to 
NRM. 
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4 MOB I TEX TERMINAL •SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Below are the reference designations listed. 

Reference Section 

Rl-01 --Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

. Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 

CCITT recommendations series X, 1984 Edition (Red 
Book) X.21 bis 



ISO-standards: 



ISO 3309-1984(E) 
ISO 4335-1984 (E) 
ISO 7809-1984(E) 
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ABSTRACT 

This document is a specification of the interface for a 
fixed terminal with X.25 interface, connected to the 
MOBITEX network. 
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1 INTRODUCTION 



1.1 GENERAL 

The designation 'terminal' for a fixed terminal in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions for X.25 packet layer and link layer. 

Connection of a terminal with X.25-interface can be done 
directly to the MOBITEX network or through an X.25 
network. 

CCITT recommendation X.21 bis is used at the physical 
layer, LAPB is used at the link layer and X.25 is used at 
the packet layer. 

The user data in X.25 packet layer should contain HPAKs as 
_ Aescribed^ in .reference Rl-09. 
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2 PHYSICAL LAYER 



Connection is in accordance with CCITT recommendation 
X.21 bis. 



2.2 . BITRATE 

For information about permitted bitrate transmission 
rates, please refer to reference Rl-06. 
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3 LINK LAYER 

The design of the link layer follows LAPB, Link Access 
Procedure Balanced, according to CCITT recommendation 
X.25. 

The extended format modulo 128 is not supported. 
The multilink procedure MLP is not supported. 
Timeout period is Tl=3 seconds. 
Maximum number of outstanding frames are K=7. 
Number of retransmission attempts are N2=10. 
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4 PACKET LAYER 



The design of the packet layer follows CCITT 
recommendation X.25 for DTE with the following 
restrictions: 

When the terminal is using direct connection there is only 
one logical channel. The logical channel group number 
should be zero and the -logical channel number should be 
one. 

When connection is made through an X.25 network, maximum 
number of logical channels are 8. 

The delivery-bit should be set to zero in all data, 
packets. 

The qualifier-bit is ignored by the MOBITEX network. 

The sequence numbering scheme of the data packets is 
performed modulo 8. 

The standard default value for the window size is two 
packets, it is possible to change the default window size 
to 1, 3, 4, 5, 6 or 7 packets. 

The standard default value for the packet size is 128 
octets. It is possible to change the default packet size 
to 32, 64, 256, or 512 octets. 

Interrupt, reject and registration packets are not 
supported. 

The following facilities are supported: 

- Plow control parameter negotiation. 

- Non standard default packet size. 

- Non standard default window size. 

- Reverse charging. (See note 1.) 

- Reverse charging acceptance. (See note 1.) 

A connected terminal can communicate with MOBITEX through 
a permanent virtual circuit (PVC) or through a virtual 
circuit (VC). 
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If no packets, in either direction, has been transmitted 
on the logical channel during X (default 4 and possible to 
change) minutes a virtual call will be cleared by the 
MOBITEX network if the connection is VC. 

Note 1 : Only used when connected through an X.25 network. 

The packet call request/incoming call and call accepted/ 
call connected should contain both calling DTE address and 
called DTE address (optional in CCITT X.25). 
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4.1 Diagnostic codes 

Coding of the restarting cause field and the diagnostic 
code field in a restart packet, used by the MOBITEX 
network and the connected terminal. 



c ause diagn. explanation 

- 00 local procedure error 

17 invalid packet type for state rl 

52 time expired for restart indication 

07 network operational 



Coding of the clearing cause field and the diagnostic code 
field in a clear packet, used by the MOBITEX network and 
the connected .terminal. 

cause diagn. - explanation 

0 dte originated 
0 dte clearing 

01 number busy 

72 call collision 

03 invalid facility request 

65 facility code not allowed 

66 facility parameter not allowed 



19 local procedure error' 

20 invalid packet type for state pi 

21 invalid packet type for state p2 

22 invalid packet type for state p3 
24 invalid packet type for state p4 
26 invalid packet type for state p6 
33 unidentifiable packet 

38 packet too short 

41 restart with nonzero in bits 1-4 in octet 
1 or nonzero in bits 1-8 in octet 2 

49 time expired for incoming call 

50 time expired for clear indication 

51 time expired for reset indication 

67 invalid called address 

68 invalid calling address 

69 invalid facility length 
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Coding of the resetting cause field and the diagnostic 
code field in a reset packet , used by the MOBITEX network 
and the connected terminal. 

cause diaqn. explanation 

05 local procedure error 

01 invalid p(s) 

02 invalid p(r) 

27 invalid packet type for state dl 

32 packet type not allowed (registration or 

interrupt packet) 
35 invalid packet type oh pvc channel 

37 reject packet not subscribed 

41 restart with nonzero in bits 1-4 in octet 

1 or nonzero in bits 1-8 in octet 2 
51 time expired for reset indication 



Coding of the diagnostic code field in a diagnostic 
packet, used by the MOBITEX network and the connected 
terminal. 



diaqn. explanation 

36 packet on unassigned logical channel 

38 packet too short 

40 invalid general format identifier 

50 time expired for clear indication 

51 time expired for reset indication 

52 time expired for restart indication 
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5 MOBITEX NETWOP.K LAYER 

The MPAK should be placed in the user data field in one or 
more X.25 data packets. An MPAK should be handled as a' 
complete packet sequence, according to CCITT's X.25 
recommendation # 4.3.5. 

Note: The D-bit should always be set to zero in 
communication with the MOBITEX network. 

If the transmission of an MPAK is interrupted by a 
restart, reset or clear procedure the whole MPAK should be 
retransmitted. 
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6 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4 
Rl-09, 3 



Below are the reference designations listed. 

Reference Section 

Rl-01 . Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 " Network operator information 

Rl-08 Application layer 

Rl-09 • Network layer 

Rl-ll Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 



CCITT recommendations series X, 1984 edition (Red. 
book) X.25 and X.21 bis 
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ABSTRACT 

This document is a specification of the interface for a 
fixed terminal with binary synchronous communication (BSC) 
interface, connected to the HOBITEX network. 
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1 INTRODUCTION 



1 . 1 GENERAL 

The designation "terminal" for a fixed terminal in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions. 

CCITT recommendation X.21 bis is used at the physical 
layer. The link layer is IBM's BSC (binary synchronous 
communication), see chapter 2. 

The network layer is a character oriented MPAK (BSCPAK), 
see chapter 4. 
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2 PHYSICAL LAYER 



2.1 GENERAL 



Connection is in accordance with CCITT recommendation X.21 
bis. 



2.2 BITRATE 

For information about permitted bitrate transmission 
rates, please refer to reference Rl-06. 
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3 LINK LAYER 

The design of the link layer follows IBM General 
Information - Binary Synchronous communications, GA27-3004 
with the following restrictions: 

Point-to-point connection is used. The Mobitex network has 
a retry timeout of 3 seconds. 

ITB and RVI will be handled by the Mobitex network when, 
received, but is never transmitted. 

Transparent mode is not handled by the Mobitex network. 

SOH can be received but the content of the header is not 
interpreted. SOH is never transmitted. 

The Mobitex network retransmits max 15 times. 
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4 NETWORK LAYER 

The network layer use BSCPAK. A BSCPAK is a character- 
oriented MPAK, HPAKs are bit-oriented and are described in 
reference Rl-09. 

BSCPAK is EBCDIC-coded , see chapter 6. 

All MPAK, except MPAK DATA, HPDATA and EXTPAK can be 
translated to BSCPAK. 

Sendlist is not handled. 

All numeric fields are right adjusted with preceding 
zeroes. 

BSCPAK shall be handled in the same way as corresponding 
MPAK. 

Maximum length for a BSCPAK is 548 octets (BSCPAK TEXT 
without sendlist) . 

A BSCPAK may be divided into several blocks, each of which 
ends with ETB except the last one which ends with ETX. 

The content of the text field in a BSC-block is a BSCPAK 
(or part of BSCPAK) in either direction, to or from the 
Mobitex network. 

STX precedes and ETX ends a BSCPAK. 
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5 SPECIFICATION OF BSCPAK 

BSCPAK shall be handled, according to reference Rl-09, in 
the same way as corresponding MPAK. Below is a description 
of the translation between bit-oriented MPAK and the 
character oriented BSCPAK. 

All BSCPAKs consist of one BSCPAK header and one part with 
typedependent components . 

All characters in a BSCPAK shall be in EBCDIC code. 



BSCPAK, COMMON COMPONENTS 



BSCPAK-field 
sender 
adressee 

_ciass .. , .... . 
extern_F 
type ~ • 
mailbox F 
digital~F 
sendlist_F 
unknown_F 
reserve_F 
trafstate 

Length 26 octets. 



Ex. sender = 123456 

octet 1 



octet comment 



1- 8 


only digits 


9-16 


only digits 


17 


only digits 


18 


0 or 1 


19-20 


only digits 


21 


0 or 1 


22 


0 or 1 


23 


0 


24 


0 or 1 (0 from Mobitex) 


25 


0 


26 


0 ... 7 (0 to Mobitex) 



Octet 1 will be transmitted first. 
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5.2 BSCPAK COMPONENTS 

The following components are described in this chapter: 

TEXT 

STATOS 

SOSINFO 

SOSACK 

CONREQ 

SOSCONREQ 

ADDCONREQ 

CONGRA 

CONORD 

CONREA 

DISCON 

EXTCONREQ 

CLOOPON 

CLOOPOFF 

LOGINREQ 

LOGINGRA 

LOGINREF 

LOGOUT 

LOGOOTORD 

ACTIVE 

INACTIVE 

DIE 

LIVE 

VICESOSRX 

SOSRX 

GROOPLIST 

FLEXREQ 

PLEXLIST 

TIME 



A292S1533 
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* TEXT without adress list: 
BSCPAK-field octet comment 



bscpak-header 

time 

text 



Length 37-548 octets. 



1-26 

27-36 decimal digits (YYMMDDHHMM) 
37- all characters included in 
Mobitex textcode (EBCDIC- 
coded), 1-512 characters 



* STATUS without adress list: 
BSCPAK-field octet comment 



bscpak-header 
time 

status code 
Length 39 octets. 



1-26 

27-36 decimal digits (YYMMDDHHMM) 
37-39 only digits 000 ... 255 



SOSINFO 
BSCPAK-field 



bscpak-header 
time 

static emergency 
information 



dynamic emergency 
information 



Length 36-548 octets. 



27-36 decimal digits (YYMMDDHHMM) 

37- all characters included in 
Mobitex textcode (EBCDIC- 
coded), 0-256 characters 

'37- all characters' included in 
Mobitex textcode (EBCDIC- 
coded), 0-256 characters 



* SOSACK 
BSCPAK-field 



octet comment 



bscpak-header 1-26 

time 27-36 decimal digits" (YYMMDDHHMM) 
emergency 

acknowledgement status 37-39 decimal digits 000.. 255 
Length 39 octets. 
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CONREQ 
BSCPAK-field 



octet comment 



bscpak-header 
line number 

connection identity 

Length 32 octets. 



1-26 

27-29 decimal digits 000.. 255 

(000 from terminal) 
30-32 decimal digits 000.. 255 



BSCPAK-field 



bscpak-header 
line number 



connection identity 
Length 32 octets. 



octet comment 



1-26 

27-29 decimal digits 000.. 255 

(000 from terminal) 
30-32 decimal digits 000.. 255 



ADDCONREQ 
BSCPAK-field 



bscpak-header 
line number 



1-26 
27-29 



decimal digits 000.. 255 
(000 from terminal) 
decimal digits 000.. 255. 



connection identity 30-32 „ 

additional information 33-52 all characters included in 
Mobitex textcode (EBCDIC- 



Length 52 octets. 



CONGRA 
BSCPAK-field 



octet comment 



bscpak-header 
line number 

connection identity 

Length 32 octets. 



1-26' 

27-29 decimal digits 000.. 255 

(000 from terminal) 
30-32 decimal digits 000.. 255 
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* CONORD 
BSCPAK-field 


octet 


comment 


bscpak-header 


1 


-26 




line number 


27 


-29 


decimal digits 00O..255 








(000 from terminal) 


connection identity 


30 


-32 


decimal digits 000.. 255 


Length 32 octets. 








* CONREA 
BSCPAK-field 


octet 


comment 


bscpak-header 


l 


-26 




line number 


27 


-29 


decimal digits 000.. 255 


- 






(000 from terminal) 


connection identity 


30 


-32 


decimal digits 00.0.. 255 


Length 32 octets. 








* D I SCON 








BSCPAK-field 


octet 


comment 


bscpaic-header 


1 


-26 




line number 


27 


-29 


decimal, digits 000.. 255 








(000 from terminal) 


connection identity 


30 


-32 


decimal digits 000.. 255 


Length 32 octets. 








* EXTCONREQ 








oaLr ak— r le la 


octet 


comment 


bscpak-header 


1 


-26 




line number 


27 


-29 


decimal digits 000.. 255 








(000 from terminal) 


connection identity 


30 


-32 


decimal digits 000.. 255 


subscr. no. in ext. 








network 


33 


-52 


decimal digits 


Length 52 octets. 








* CLOOPON 








BSCPAK-field 


octet 


comment 


bscpak-header 


1 


-26 




line number 


27 


-29 


decimal digits 000.. 255 








(000 from terminal) 


Length 29 octets. 
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* CLOOPOFF 








BSCPAK-field 


octet 


comment 


bscpak-header 
11ns numbs r 


1 
27 


-26 

-29 


decimal digits 000.. 255 
(000 from terminal) 


• Length 29 octets. 








* LOGINREQ 








BSCPAK-field 


octet 


comment 


bscpak-header 
MAN 

password 


1 
27 
35 


-26 
-34 
-42 


only decimal digits 
all characters included in 
Mobitex textcode { EBCDIC- 
coded) 


Length 42 octets. 








* LOGXNGRA 








BSCPAK-field 


octet 


comment 


bscDak-header 
HAN 


1-26 
27-34 


only decimal digits ■ 


Length 34 octets. 








* LOGINREF 








BSCPAK-field 


octet 


comment 


bscpak-header 
MAN 


l 
27 


-26 
-34 


only decimal digits 


Length 34 octets. 








* LOGOUT 








BSCPAK-field 


octet 


comment 


bscpak-header 
MAN 


1 
27 


-26 

-34 


only decimal digits 


Length 34 octets. 
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* LOGOUTORD 






BSCPAK— f ield 


octet comment 


bscpak-header 
HAN 


1-26 

27-34 only decimal digits 


Length 34 octets. 






* ACTIVE 






BSCPAK-field 


octet comment 


bscpak-header 


1-26 


Length 26 octets. 






* INACTIVE 






BSCEAK-field 


octet comment 


bscpak-header 


1-26 


Length 26 octets* 






* DIE 






BSCPAK-field 


octet comment 


bscpak-header 


1-26 


Length 26 octets • 






* LIVE 






BSCPAK-field 


octet comment 


bscpak-header 


1 


-26 


Length 26 octets. 






* VICESOSRX 






BSCPAK-field 


octet comment 


bscpak-header 


1 


-26 


Length 26 octets. 






* SOSRX 
BSCPAK-field 


octet comment 


bscpak-header 


1-26 


Length 26 octets. 
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GROOPLIST 
BSCPAK-field 



bscpak-header 

number of HAM 

MAN 1 

MAN 2 

MAN 3 

MAN 4 

MAN 5 

MAN 6 

MAN 7 

MAN 8 

MAN 9 

MAN 10 

MAN 11 

MAN 12 

MAN 13 

MAN 14 

MAN 15 

Length 148 octets. 



octet comment 



"T=2T 
27-28 
29- 36 
37- 44 
45- 52 
53- 60 
61- 68 
69- 76 
77- 84 
85- 92 
93-100 
101-108 
109-116 
117-124 
125-132 
133-140 
141-148 



1..15 

only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 



digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 



FLEKREQ 
BSCPAK-field 



bscpak-header 
Length 26 octets. 



octet comment 



: FLEXLIST 
BSCPAK-field 



bscpak-header 

number of MAN 

MAN 1 

MAN 2 

MAN 3 

MAN 4 

MAN 5 

MAN 6 

MAN 7 

Length 83 octets. 



•octet comment 



T=2T 

27 " 1..7 

28-35 only decimal 

36-43 only decimal 

44-51 only decimal 

52-59 only decimal 

60-67 only decimal 

68-75 only decimal 

76-83 only decimal 



digits 
digits 
digits 
digits 
digits 
digits 
digits • 



TIME 
BSCPAK-field 



bscpak-header 
time 



Length 36 octets. 



octet comment 



27-36 decimal digits (YYMMDDHHMM) 
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6 TRANSLATION BETWEEN ASCII AND EDCDIC 



ASCII EBCDIC 



09 


05 


OA 


25 


DC 


or 




on 




an 






22 


7F 


23 


7B 


24 


5B 




g 


26 


50 


27 


_ 










2A. 




2B 




2C 


g 


2D 


60 


2E 


4B 


2F 


61 


30 


FO 


31 


Fl 


32 


F2 


33 


F3 


34 


F4 


35 


F5 


36 


F6 


37 


F7 


38 


F8 


39 


F9 


3A 


7A 


3B 


5E 


3C 


4C 


3D 


7E 


3E 


6E 


3F 


6F 


40 


7C 


41 


CI 


42 


C2 


43 


C3 


44 


C4 


45 


C5 


46 


C6 


47 


C7 


48 


C8 


49 


C9 


4A 


Dl 


4B 


D2 


4C 


D3 


4D 


D4 


•4E 


D5 
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52 
53 



58 
59 
5A 
5B 
5C 
5D 
5E 
5F 



E5 
E6 



62 

63 



71 
72 
73 
74 
75 



89 
91 



95 
96 



7A 
7B 
7C 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references , made to ■ 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
. referred to several times on the same page. 

Rl-06, 4 
Rl-09, 6, 7 



Below are the reference designations listed. 
Reference Section 



Rl-01 
Rl-02 
Rl-03 
Rl-04 
Rl-05 
Rl-06 
Rl-08 
Rl-09 
Rl-11 
Rl-12 
Rl-16 
Rl-17 • 
' Rl-18 
Rl-19 
Rl-20 



Arrangement of the documents 
MOBITEX System description 
General description of terminals 
Terminology 
References 

Network operator information 
Application layer 
Network layer 

Interface requirements, fixed terminals 
Other requirements, fixed terminals 
Link layer, mobile terminals 
Physical layer, mobile terminals 
Radio equipment, mobile terminals 
Other interfaces, mobile terminals 
Other requirements, mobile terminals 



The following references are made in this document: 

CCITT recommendations series V, 1984 Edition(Red 
books )X. 21 bis. 

IBM General Information - Binary Synchronous 
Communications, GA27-3004. 
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ABSTRACT 



This document is a specification of the interface for a 
fixed terminal with MOBITEX Asynchronus Communication 
(MASC) interface, connected to the MOBITEX network. 
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INTRODUCTION 



1.1 GENERAL 

The designation "terminal" for a fixed terminal in the 
MOBITEX network correspond to DTE in CCITT recommenda- 
tions . 

CCITT recommendation V.24 is used at the physical layer 
and MASC interface is used at. the link layer (reference 
Rl-19 is used for link layer MASC). The network layer 
consists of MPAK's according to reference Rl-09.. 
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2 PHYSICAL LAYER 



2.1 



GENERAL 



Connection is in accordance with CCITT recommendation 
V.24/V.28. 

Hote: The physical layer of MASC is not directly 

compatible with the physical layer in the masc 
interface of a mobile terminal. 

However this can be done by connecting the Eollowing 
signals in the mobile unit. 



2.2 BITRATE 

For information about permitted bitrate transmission 
rates, please see reference Rl-06. 




A 292 51533 
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3 LINK LAYER 



3 . 1 GENERAL 

The link layer sends, controls and acknowledge information 
between .network and terminal. When faults are detected, 
the link layer handles retransmission. 

The design of the link layer follows PROTOCOL FOR MASC 
TYPE TERMINALS , which is described in 'reference Rl-19. 

The data in information frame is MOB I TEX packets (MPAK) 
which are described in reference Rl-09. 



3.2 FRAMES USED IN MASC 

There are two different types of frames, control frames 
and information frames {see reference Rl-19). 

The following control frames are used: 

- ACK Acknowledgement 

- NACK Negative acknowledgement 

- RACK Request for repetition of the latest sent 

ACK 

- SENS Communication link control 

- SACK Acknowledgement of a received SENS 



Note: The network will not send the frame SENS by 
default. 



Information frames. are used with the following commands: 

- B parameters in machine interface 

- M send/receive MPAK 

- E answer to an invalid command 

- F P terminal MAN request and answer 

- F Q raasc device identity 
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3.3 TIMEOUT 



The masc interface uses two timers, which are described in 
reference Rl-19. 

Note: The network will handle the "30 seconds timeout" as 
follows: 

If no answer is received within 30 seconds/ the 
network will return the frame to the sender. The 
network will then try to start up the line with a B- 
command. 



3.4 START WITH NO SUBSCRIPTION NUMBER 

The terminal has the possibility to ask the network about 
the valid subscription number. When the line is in the 
connected mode, the terminal can ask the network about 
MOBITEX subscription number. 

The terminal sends the P P command and receives the answer 
P PMAN from the network. The terminal will also receive an 
identification of the network in the F Q command. 

F P and F Q are described in reference Rl-19. 
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4 HOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4 
Rl-09, 3, 5 
Rl-19, 3, 5, 6 



Below are the reference designations listed. 



Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 HOBITEX System description 

.-R1-G3 .• < General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 

CCITT recommendations series V, 1984 Edition (Red 
books) V.24 and V.28 



Exhibit 2, p. 494 



REQDIRSMENT SPECIFICATION 1(7) 



ET/SYS PES 


ET/SYS'PES 50 


rsrs r r— 

1056 - A 296 5454 Ue 


ET/SYSC STT SfT 


I9V0-02-27 l3 c [mtsiimpad.i 


Cantel Mobitex- 


MOBITEX 

Asynchronous interface 
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ABSTRACT 

This document describes the connection of an asynchronous 
terminal to the MP AD service in the MOBITEX network. 
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TABLE OF CONTESTS 



1 INTRODUCTION 3 
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2.2 TERMINAL EQUIPMENT 4 

2.3 PRINTER EQUIPMENT (optional) 4 

2.4 BITRATE 4 

3 PROTOCOL FOR TERMINAL 5 

3.1 CONTROL SEQUENCES FROM TERMINAL TO MPAD 6 

3.2 CONTROL SEQUENCES FROM MPAD TO TERMINAL V 6 
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1 INTRODPCTION 



1.1 GENERAL 



The MP AD communicates with the terminal one character at a 
time with a start-stop protocol. The purpose with the MP AD 
service is to let customers use a standard terminal for 
communication with the MOBITEX network. 

The designation "terminal" for a fixed termial in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions . 
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2 PHYSICAL LAYER 



2.1 GENERAL 

Connection is in accordance with CCITT recommendations 
V.24/V.28. 



2.2 TERMINAL EQUIPMENT 

An asynchronous terminal of start-stop type for serial 
data transmission is used. The communication uses 1 start 
bit, 8 data bits, 1 stop bit and no parity. The screen 
should be 24 lines x 80 columns. The terminal should have 
an advanced video option installed to use the reversed 
video facility. 

If the MPAD-connected terminal has a printer port or 
auxiliary -port, a printer can be connected to this port. 
Messages to/from the terminal can be directed to this 
printer if the terminal can interpret the printer-port 
setting commands described in chapter 3. 



2.3 PRINTER EQUIPMENT {optional) 

The printer should have at least 24 columns, preferably 80 
columns width. The transmission rate and communication 
type depends on the available printer-port on the 
terminal. The printer should be able to use the same 
character-set as the terminal, see chapter 3. 



2 . 4 BITRATE 

For information about permitted transmission rates, 
refer to. reference Rl-06. 
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3 PROTOCOL FOR TERMINAL 

The terminal should comply with ANSI/VT100 according to 
the following specifications that is a subset of ANSI 
X3.41 1974 and ANSI X3.64 1979. 

The terminal should be able to : 

* transmit and receive all characters described in 
MOBITEX text code (please refer to reference Rl-06). 

* transmit ASCII-character 127 (DEL). 

* receive ASCII-character 7 (bell) and then give an 
audible signal. 

* receive ASCII-character 10 (LF) and then do a line- 
feed. 

* receive ASCII-character 13 (CR) and then do a 
carriage return. 



interpret the control sequences described in chapter 
3.2 
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3.1 CONTROL SEQUENCES FROM TERMINAL TO MP AD 

The following control sequences should preferably be 
generated by arrow-marked keys. 

ESC O A (arrow up) 

ESC 0 B (arrow down) 

ESC O C (arrow right) 

ESC O D (arrow left) 

The following control sequences should preferably be 
generated by the keys on an auxiliary keypad. 

ESC Op (0) 

ESC 0 q (1) 

ESC O r (2) 

ESC 0 s . (3) 

ESC O t (4) 

ESC 0 u .(5) 

ESC 0 v (6) 

ESC O w (7) 

ESC OX (8) 

ESC O y (9) 

ESC 0 m (dash) 

ESC 0 1 (^lowercase E) (comma) 

ESC 0 n (period) 

ESC 0 M (ENTER) 

ESC 0 P (PF1) 

ESC 0 Q (PF2) 

ESC 0 R (PF3) 

ESC O S (PF4) 



3.2 CONTROL SEQUENCES FROM MPAD TO TERMINAL 

ESC = Set terminal in keypad application mode 

ESC 7 Save cursor 

ESC 8 Restore cursor • 

ESC [ 7 m Set reverse video 

ESC [ 0 ra All video attributes off 

ESC [ 5 i Enter printer controller mode 

ESC [ 4 i Exit printer controller mode 

ESC [ 0 k Erase line after cursor 

ESC E Next line 

ESC [ 20 h Set new line mode 

ESC [ x;y H Move cursor to line x and column y 

ESC [ ? 1 (=one) h Set cursor key mode 

ESC [2 J Erase all of the display 



A33JSI5M 
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4 HOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to- 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4, 5 

Below are the reference designations listed. 

Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

Hl-03 ' General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information - • 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 



CCITT recommendations series V, 
books) V.24 and V.28 



ANSI X3.41 1974 
ANSI X3.64 1979 



1984 Edition {Red 
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This document specifies general requirements for fixed 
terminals, connected to the MOBITEX network. 
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1 GENERAL 



A fixed terminal is connected with a line interface for 
packet switching and line connection for line connection 
traffic (primarily speech). If the fixed terminal is 
connected to the mains, there are certain requirements for 
electrical safety. 



2 ELECTRICAL SAFETY 

For information about electrical safety requirements, 
please refer to Rl-06. 



3 SPECIFICATION OF LINE CONNECTION 

A fixed terminal should permit line connection traffic as 
a comolement to message traffic. For this to be possible, 
it is" necessary to have a real time connection between 
terminal and network in addition to the message traffic 
interface. A connection of this type can be used for 
transmitting speech for example. 

For information about line connection requireraements, 
please refer to Rl-06. 

TYPE OF CONNECTION: 4 wire speech connection with 

one speech direction per line 
pair. 

CONNECTION: ISO DIS 8877 plug" of European or 

D.S. type. 

FREQUENCY RANGE: 300 - 3400 Hz 

RECEIVER LEVEL DIRECTION -15 30 dBm 

SENDER LEVEL DIRECTION "10 23 dBm 

SIGNAL/NOISE RATION REC./SEND. : Greater than 40 dB 
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4 MOB I TEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with- the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Below are the reference designations listed. 

Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 . HOBITEX System description 

Rl-03 . General description of terminals 

Rl-04 Terminology 

Rl-05 ., References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equinraent, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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EXPLANATION AND MODIFICATIONS 

This chapter has been newly added. It is an addendum providing a preliminary 
specification of additional requirements for portable terminals designed for 
operation on the Mobitex network. The primary motivation for this addendum is 
the need to provide a low power operating mode for portable units, to extend 
the operating time of their self-contained batteries. Because enhancements have 
been made to network signalling protocols over the air interface, these 
additional requirements will have some effect on the operation of mobile units 
as well. A careful review of this chapter is therefore required of all terminal 
designers and manufacturers. 

Since the addendum document was printed, several changes have been made 
to the protocol. They wfll be included in a future revision of the ERfTEL - 
provided specification. These changes, which should be . applied to the MTS 
15.1 document immediately following, are detailed below so that this very 
important new information can be brought to the attention of interested parties 
in a timely manner. 

1. Section 3.5, page 8: the first paragraph should be changed to read: 

If the terminal has lost consecutive <SVP6> signals over a period 
less than 60 seconds, it should remain in the operating state to 
synchronize again. If the terminal has not succeeded in synchronizing 
within 60 seconds, it should initiate the roaming procedure. 

Z Section 3.6, page 12: the two paragraphs under the heading "Evaluation of 
other base stations" should be changed to read: 

The evaluation of base stations on the CURRENT-SYSTEM-CHANNEL 
should be based on the average received signal strength over a time 
period indicated in <SVP6> (default value, 60 seconds). 

The integration time for evaluating base stations on other channels is 
indicated In <SVP6> (default value, 3 RSSI-PERIODS). . 

3. Section 3.8.1, page 13: the second paragraph under the heading "UP LINK 
TRAFFIC" should be changed to read: 

For uplink traffic the terminal should enter the OPERATING state and 
then follow the normal access rules, Le., wait for a <FRI> signal and 
then choose a random slot in which to transm'rt. 

4. Section 3.10, page 17: This section deals with voice operation and may be 
disregarded. 
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5. Section 4, pages 25 and 28: Note that the <SVP5> and <SVP6> may 
contain up to 186 MANs each. A parameter will be added in the currently 
unused portion of the primary block of <SVP5> and <SVP6> to indicate 
the number of MANs in the mail list or traffic list, respectively. 

6. Section 4, pages 28 and 29: parameters will be added in the currently 
unused portion of the primary block of <SVP6> to indicate signal strength 
evaluation times for the CURRENT-SYSTEM-CHANNEL (default 60 seconds) 
and other channels (default 3 RSSI-PERIODS), (See item 2. above). 

7. Section 4, page 29: the entry for TRANSACTION-TIME" should be changes 
to read: 

States the time the terminal should stay in OPERATING state after (1) 
reception of a message from the network, and (2) transmission of a 
message to the network. (0-255) X 250 ms. Default value: 40 (10 
seconds). TRANSACTION-TIME starts after transmitting or recieving an 
<ACK>, respectively. 

8. Section 6, pages 35 and 36: the following three items listed as design 
recommendations have been changed to design requirements, and their 
functionality must be included in portable units: 

Automatic change to mobile terminal operation (page 35) 

User notification of 'lost contact 1 (page 36) 

Display RSSI to user before transmitting (page 36) 

The remaining three items - manual selection of operating mode, prevention 
from automatic quick channel monitoring, and manual initiation of channel 
monitoring - continue to be design recommendations. 



ADDITIONAL INFORMATION 

In the "INFO" MPAK (See MTS 09A2, pages 107 and 108), portable terminals 
will be defined as terminal type number 4.The INFO MPAK will also now include 
a parameter indicating the operating mode of the portable unit (mode = mobile 
terminal mode; mode 1 = battery saving mode). 

In the MASC interface (see MTS 19A.2), new commands will be added to 
accommodate portable terminals. Details will be provided later. 
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PROTOCOL FOR HAND-HELD PORTABLE 
TERMINALS FOR USE IN MOBITEX 



PRELIMINARY SPECIFICATION. 



ABSTRACT 



This document specifies additional requirements for hand- 
held portable terminals to be connected to the MOBITEX 
system. 

An interface for hand-held portable terminals, where power 
conservation is one prime objective, is defined. 

This document should be considered as an ADDENDUM to the 
MOBITEX Terminal Specification (MTS) for 8 kbps mobile 
terminals, LZBA 703 1001, R1A. 



A 232 5X33/3 
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1 INTRODUCTION 

This document specifies additional requirements for hand- 
held portable terminals to be connected to the MOB I TEX 
system. 

It should be considered as an ADDENDUM to the complete 
MOBITEX Terminal Specification for 8 kbps mobile 
terminals, LZBA 703 1001, R1A. 

If certain requirements are made for hand-held portables 
these are made in this document. It could either be new 
additional requirements or new requirements that replaces 
ones that are made in the specification for ordinary 
mobile terminals. 



2 GENERAL DESCRIPTION 

A hand-held_j?or table terminal is basically a mobile 
terminal and should therefore conform to the requirements 
for mobile terminals, but with the additional ability to 
go into low power drain operating mode and wakeup when 
required to receive messages from the network. 

When the hand-held has received its messages it goes 
asleep again. 

One limitation for portables in this mode is that messages 
to these terminals may be delayed during the time when the 
portable is asleep. 

Whenever a hand-held wants to send a message it 
immediately wakes up, waits for a free-signal and sends 
the message. The terminal then stays awake for a period of 
time in order to be be able to receive a quick message 
response. 

The roaming procedure is essentially the same as for 
ordinary mobiles, but is controlled from separate sweep- 
parameters for hand-held terminals. The hand-held 
terminals performs the base evaluation during its awake 
time. 
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This protocol for hand-held terminals defines four new 
subtypes of the sweep-signal, <SVP>. These subtypes are 
numbered from 3 to 6.. 



<SVP3> - Sweep frame of subtype 3 

Includes roaming parameters and channel list used by 
hand-held terminals. <SVP3> corresponds to <SVP1> 
used by mobile terminals. 



<SVP4> - Sweep frame of subtype 4 

Contains channel numbers and channel types used in 
fleet division procedure. <SVP4> corresponds to 
<SVP2> used by mobile terminals. 



<SVP5> - Sweep frame of subtype 5 



Contains a list of— terminal MAN that has messages 
stored in the network mailbox. 



<SVP6> - Sweep frame of subtype 6 

Contains a list of terminal MAN or Group MAN that 
will have traffic from the network during this sweep 
cycle. 

This sweep frame also contains timing parameters for 
synchronization and message transfer. 
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3 OPERATING PRINCIPLES 



3.1 START OP PROCEDURE 

When the portable is powered up for the first time and/or 
when it has lost synchronization with the network or lost 
important information/parameters, it should consider 
itself to be in normal mobile terminal mode and act 
according to that. 

When the hand-held has found a system channel on a base 
station to use, received the relevant parameters from the 
base and synchronized to it, the terminal should send MPAK 
ROAM or ACTIVE according to the roaming procedure. 

The hand-held always has the possibility to go to normal 
mobile terminal mode , e.g. when the terminal is put in a 
power charger or for a major data transaction session when 
you want to be active all the time. In order to inform the 
network of this change of mode, the hand-held sends a new 
MPAK called MODE. " 



3.2 STATES 

There are two different states that a hand-held terminal 
could enter when it is in the low power drain mode; 
STANDBY state or OPERATING state. 

The STANDBY state should be considered as a 'sleeping' 
mode where only time keeping functions for synchronizing 
the terminal to the base station are in operation. 

In the OPERATING state the terminal should be considered 
as fully operational. 
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3.3 TRAFFIC LIST 

The hand-held terminal is notified in a TRAFFIC LIST that 
traffic will sent to the terminal. 

The TRAFFIC LIST contains the TERMINAL-MAN or the GROUP- 
MAN of those terminals that should remain in the OPERATING 
state in order to be available for the down-link traffic 
from network. 

The TRAFFIC LIST is part of a new <SVP>-frame of SUBTYPE 
6, denoted <SVP6>-f rame. 

Terminals not included in the TRAFFIC LIST may directly go 
back to STANDBY, state in order to save battery. ' 



3.4 MAIL LIST 

Messages not acknowledged by the terminal may be stored in 
the network mailbox according to the conditions describes 
•in Rl-09, 8kbps MTS. 

In order to inform terminals that have messages in the 
network mailbox, the MAIL LIST is introduced. 

The MAIL LIST contains a list of. those terminal MAN having 
messages in the mailbox. The MAIL LIST is within the 
<SVP>-frame of subtype 5, denoted <SVP5>. 
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3.5 SYNCHRONIZATION TO THE NETWORK 

Hand-held terminals using the this battery saving protocol 
cyclically goes from the STANDBY state to the OPERATING 
state. 

The terminal must be synchronized to the <SVP6> (TRAFFIC 
LIST) sent from the network. The <SVP6> frame is sent 
periodically from the network on the system channels where 
hand-held terminals can operate and use the battery saving 
protocol. 

The <SVP6> also contains the parameter TIME-TO-NEXT 
indicating the remaining period of time from this <SVP6> 
to the next time the terminal should enter the OPERATING 
state. 

TIME-TO-NEXT = time from first bit (bit 1) in the 

framehead of the received <SVP6> to the 
next time the terminal should enter the . 
OPERATING state. 

The <SVP6> also contains the parameter CYCLE-TIME which is 
the nominal cycle time between the start of two operating . 
states. 

The length of the CYCLE-TIME parameter is a compromise 
between response-time requirements and power consumption 
requirements of the terminal. 

Normally the terminal uses the TIME-TO-NEXT parameter in 
the <SVP6> to synchronize to the next time to enter the 
OPERATING state. If one or more of the <SVP6> frames are 
lost, the terminal should use the CYCLE-TIME parameter in 
order not to lose synchronization. 

Once the terminal has entered the OPERATING state it 
remains in this state until it receives an <SVP6> frame 
with a TRAFFIC LIST where the terminal is not included. 
The <SVP6> is terminating the transmission of the sweep 
frames . 

If the network is going to send other sweep frames when 
the terminals are In the OPERATING state, they will be 
sent prior the <SVP6> frame. 

If none of the <SVP3> to <SVP6> has been received within 2 
seconds from the transition to the OPERATING state, the 
terminal could return to STANDBY. 

After the reception of every <SVP3> to <SVP5> the terminal 
stays in OPERATING state for another 2 seconds or till it 
receives an <SVP6>. 
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If the hand-held consider itself as having lost 
synchronization to che network, e.g. lost of a number o? 
consecutive <SVP6>, it should stay in OPERATING sfcat* to 
synchronize again. 

Example 1 : 

Terminal uses TIME-TO-NEXT for synchronizing. 

Base <SVP6> <SVP6> 

I I TIME -TO— NEXT 1 | 



CYCLE-TIME 



Terminal — 'opr^ STB — 'opr'-STB 

OPR = terminal in OPERATING state 
— STB._= terminal in STANDBY state 

Example 2 : 

Terminal is using the CYCLE-TIME when <SVP6> is lost to 
keep synchronization. 



HlIME-TO-NEXT 
— CYCLE-TIME - 




OPR STB~ 



OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 



Example 3: 

Multiple sweep frame could be sent during the OP ERAtt re- 
state. 



<SVP3>,<SVP4>,<SVP5>,<SVPS> 

II!! 



'TIME-TO— NEXT 
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Terminal does not receive any sweep frame within 2 seconds 
from the start of the OPERATING state and returns to 
STANDBY. 



—CYCLE-TIME - 



Example 5: 

The terminal receives a <SV?3> but the <SVP6> is not 
received so the OPERATING state is terminated by the 2 
second timeout. 

The timeout-is counted from the reception of the <SVP3> 
frame. 

Base <SVP3> 
I 
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3 . 6 ROAMING 






The roaming procedure for hand-held terminals follows 
basically the roaming procedure for mobile terminals 
described in Rl-16. 




Since a hand-held terminal is most of the time in the 
STANDBY state, the normal monitoring of the roaming 
procedure must be carried out during the time when the 
terminal is in the OPERATING state. During the OPERATING 
state the terminal measures the averaged received signal 
strength and calculates a roaming value. 




The system parameters controlling the roaming procedure 
for hand-held portables are defined in the <SVP3>-f rarae. 
This gives the possibility to have different parameters 
for mobile terminals (defined in the <SVP1> frame ) and 
for hand-held portables. 




In order to control the performance of the terminals 
roaming procedure, different roaming parameters can be set 
in the <SVP3>-f rame from the network. Here are some 
examples described and the impacts on the terminals 
performance. 




Example 1: 






If SCAN TIME = 0 the terminal only monitors the 
CORRENT_SYSTEM_CHANNEL during the OPERATING state. 




At evaluation, if the roaming value < BAD_BASE the 
terminal goes to the 'quick channel monitoring' procedure 
since no other channels has been detected. 




Base : <SVP6> 
i 


<SVP6> 
1 




Term : "Wr 1 STB 'oPR 1 STB 




m = monitor CURRENT SYSTEM CHANNEL 
OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 




The other sweep frames are not shown in this figure but 
are coming before the <SVP6> frame if they are sent out. 
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Example 2 : 



If SCANJTIME = 1 ... 255, the terminal monitors other 
channels according to the channel list information the 
mobile has derived in the <SVP3> or from the default list. 

The start of the scan period is only critical in that 
sense that the terminal must not leave the system channel 
and monitor another channel when it should be in OPERATING 
state. 

The terminal should not leave CURR£NT_SYSTEM_CHANNEL and 
monitor other channels during the sweeD cycle if it is 
addressed in the TRAFFIC LIST. 




m = monitor CORRENT_SYSTEM_CHANNEL 
s = scan other system channels 
r = RSSI_PERIOD 
OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 

Please see the chapter ROAMING in Rl-16 for further 
information. 
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Criteria foe Leaving base 






The same criteria for leaving the CURRENT BASE applies for 
a hand-held terminal as the mobile terminal but with the 
parameters in the <SVP3> frame. The fifth criteria (item 
-5-) is not valid for hand-held terminals. 




Please see the chapter ROAMING in Rl-16 for further 
information. 




Evaluation of other base stations : 




The evaluation of base stations on the CURRENT S¥ STEM- 
CHANNEL , should be based on the averaged received sianal . 
strength from at least 60 seconds or some other suitable 
integration time. 




When evaluating other channels than the 
- CURRENT_S¥.STEM CHANNEL-,- -roaming- values from at least three • 
(3) RSSI PERIODS should be averaged. 




Quick channel monitoring : 






In quick channel monitoring when the SCAN TIME = 0 and 
when the terminal has found a channel with a 
roaming value > GOOD_BASE, the terminal should remain on 
the channel for at least 5 seconds during the measuring of 
received signal strength. Please refer to 'quick channel 
monitoring' part (item -4-}. of the ROAMING chaDter in 




At Power On 






When the hand-held terminal is switched on it should use 
the stored CURRENT_SYSTEM_CHANNEL and the CURRENT BASE. 




If there is no CURRENT BASE stored the terminal directly 
starts the quick channel monitoring procedure using the" 
default list of system channels. When a CURRENT SYSTEM- 
CHANNEL and a CURRENT BASE has been found and the MPAK 
ROAM has been sent to the network, the terminal 
synchronizes to the <SVP6>-f rames . 


H«p.-,»! 
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3.7 FLEET DIVISION OF HAND-HELD PORTABLES 

In order to assign a certain system channel (and/or access 
channel) to hand-held terminals or parts of the fleet of 
the hand-held terminals a <SVP>-f rame of SUBTYPE 4 is 
introduced, denoted <SVP4>-f rame . The <SVP4>-f rame should 
be interpreted in same way as the <SVP2>-frame for mobile 
terminals, described in 8kbps MTS section Rl-16. 



3,8 MESSAGE TRANSACTIONS 
3.8.1 OP LINK TRAFFIC 



The access requirements for up-link traffic from a hand- 
held terminal are basically the same as for a mobile 
terminal. 

A hand-held terminal that is going to transmit a message 
to the network enters the OPERATING state directly and 
waits for a valid <FRI>-frame from the network accordinq 
to the 8kbps MTS. 

When the terminal makes an access request for data using 
the <ABD>-frame , the terminal should follow the 8kbps MTS 
dialogues and remain in OPERATING state till the <MRM>- 
frame is transferred successfully or when the dialogue 
terminates for any reason. 



After the message is successfully transferred to the 
network the hand-held terminal remains in OPERATING state 
for TRANSACTION-TIME, defined in <SVP6>, before it goes 
back to STANDBY state. This gives a possibility for 
transferring an answer back to the hand-held without any 
delays caused by the waiting time to the next TRAFFIC LIST 
transmission. This function could be considered as if a 
'logical down-link channel' has been opened to the 
terminal for TRANSACTION-TIME. 
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3.8.2 DOWN LINK TRAFFIC 

Hand-held terminals having down-link traffic is addressed 
in the TRAFFIC LIST. 

When the hand-held terminal receives a TRAFFIC LIST that 
contains one of its terminal addresses (TERMINAL MAN or 
GROUP MAN) it stays in OPERATING state and awaits one 
message. 

When the message is successfully received the terminal 
stays in OPERATING state for TRANSACT ION-TIME in order to 
be able to receive more down-link messages cominq from the 
network. The parameter TRANSACTION-TIME is included in the 
<SVP6>-frame, and is the same as for up-link traffic. 

If no message has been received within the TRANSACTION- 
TIME elapsed from the reception of the last message, the 
terminal can leave OPERATING state. 

The terminal can also leave OPERATING state when it . . 
receives a TRAFFIC LIST without any of the terminal 
addressees. 

When a hand-held terminal is ordered to another channel 
for down-link data transmission, <BECD> frame from network, 
the hand-held terminal should remain in the OPERATING 
state until the data transmission dialogue is completed 
according to the 8kbps MTS. 

Terminals not included in the TRAFFIC LIST may directly go 
to STANDBY state in order to save battery. 



Example 1: 

Terminal is not in traffic list 
Base : <SVP6> <SVP6> 



Term 




STB"" 




"STB" 



OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 
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Terminal is in traffic list of <SVP6> and the 
network has one <MRM> to transmit. 



<SVP6> <MRM> 



• tt ^ 



<SVP6> 
I 



TT = TRANSACTION— TIME 

OPR = terminal in OPERATING state 

STB = terminal in STANDBY state 

Example 3: 

Terminal is in traffic list of <SVP6> and the 
network transmits multiple <MRM> within the sweep 
cycle. e ■ 

Base : <SVP6> <MRM> <MRH> <SVP6> 



TT = TRANSACTION-TIME 

OPR = terminal in OPERATING state 

STB = terminal in STANDBY state 
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3 . 9 ACTIVATION / INACTIVATION 

The hand-held terminal use of the ACTIVE/INACTIVE packet 
has been modified to better suit their environment and 
application. 

Hand-held portables used in-doors will lose contact with 
the network. much more frequently then mobile terminals. 
Hand-held terminals should therefore not send ACTIVE due 
to "lost contact' according to the roaming procedure since 
this will cause considerable system signalling overhead. 

Hand-held terminals should send INACTIVE / ACTIVE when 
switched-of f and switched-on respectively. 

When a hand-held terminal is addressed in the MAIL LIST it 
has the possibility to empty the mailbox by sending an 
ACTIVE packet. 



Terminal is in mail list of <SVP5> and the network 
has one or more <MRM> placed in mailbox. 

Base : <SVP5> <ACK> <MRM2> <SVP6> 

III I 
Term : <MRM1> <ACK> 

I TT H— TT H 

' OPR '"STB 'oPR^ — STB - 



TT = TRANSACTION-TIME 

OPR = terminal in OPERATING state 

STB = terminal in STANDBY state 

MRM1 = MPAK ACTIVE 

MRM2 = any MPAK from mailbox 
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3.10 LINE CONNECTION 

Call set-up and disconnection procedures for line 
connection to a hand-held terminal follows the 
requirements in the 8kbps MTS. 

When a hand-held terminal is called from the network for a 
line connection, the terminal is addressed in the TRAFFIC 
LIST with the TERMINAL MAN or one of the GROUP MAN. The 
terminal remains in the OPERATING state and follows the 
normal procedure for call set-up described in the 8kbps 
MTS. The terminal can leave the OPERATING state when the 
call is disconnected, according to the dialogues in the 
8kbps MTS. 



When a hand-held terminal initiates a call set-up for a 
line connection, the terminal enters OPERATING state 
before sending the line connection request, and stays in 
this state until the call is disconnected, according to 
the 8kbps MTS. 
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4 ADDITIONAL FRAMES - DATA LINK LAYER 


FRAME TYPE <SVP>, 


Sweep signal 


APPLICATION The sweep signal is a periodically 

recurring signal from BASE. An <SVP> is 
transmitted by. BASE for two reasons: 


1) 




<SVP> marks the start of a sweep 
cycle. 


2) 




<SVP> contains system 
parameters. 


<SVP> has 2 different subtypes for mobile 
terminals and 4 subtypes for hand-held 
portable terminals : 


SUBTYPE 1 




states the values of system 
parameters for mobile terminals 


2 




scates the frequency of • 
different channel types for 
mobile terminals 


3 




subtype only for hand-held 
terminals using the battery 
saving protocol described in 
this document. This subtype 
contains the system parameters 
for the hand-held terminals. 


4 




states the frequency of 
different channel types for 
hand-held terminals. 


5 




includes the MAIL LIST for 
terminals (may be used both by 
mobile terminals and hand-held 
terminals) 


6 




includes the TRAFFIC LIST and 
the timing parameters for hand- 
held terminals 


Note 1: <SVP> of subtype 1 and 2 are not described in this 
Addendum. Please refer to 8kbps MTS Rl-16. 


Note 2: For <SVP5> 
correctly 
the whole 


and <SVP6>, the hand-held should use 
received following blocks, even though 
frame may not be correct. 
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<SVP> , 


SUBTYPE 3 


- states the values of system 
parameters for hand-held 
terminals. 


PRIMARY BLOCK 












01 02 03 
i i 


22 


23 24 


25 26 27 


28 29 30 31 32 






MOB 


0 0 0 


0 1111 






33 34 35 
1 I 


36 37 38 


39 40 


41 42 43 


44 45 46 47 48 
i i i i 






PRIO 


MASK 


BLOCK 






49 50 .51 


52 53 54 
i i i 


55 56 
i 


57 58 59 


60 61 62 63 64 
i i i i 






SVPTYP 


TXPOW 






65 66 67 


68 69 70 
i i t 


71 72 


73 74 75 

i i 


76 77 78 79 80 
i i i i 






RSSI_PROC 


RSSI_PERIOD 






81 82 83 
1 1 


84 85 86 
1 1 J. 


87 88 


89 90 91 


92 93 94 95 96 
till 






0 0 0 


0 0 0 


0 0 


MAX_REP 






97 




104 


105 


112 






BASEST 


SCANJIIME 






113 

l 1 i 


1 1 1 


120 
i 


121 


128 






BAD_BASE 


GOOD_BASE 






129 




136 


137 


144 






BETTER_BASE 


0 0 0 


0 0 0 0 0 






145 








160 






PARITY 
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SVPTYP 


States the <SVP> subtype, value 
00000011 in this case"." 




TXPOW 


States the decrease in output 
power (0-255 dB below nominal, 
level) to be used by the hand- 
held terminal. The default value 
of 0 is used until this signal 
is received. 




RSSI_PROC 


States the method of the signal 
strength measurement: 

0 = FRAME 

1 = CONTINUOUS 

The default value is FRAME. 




RSSI_PERIOD 


Time used by the roaming 
algorithm (0-255 *20 ms) . 
Default value: 148 (2 960 ms ) . 




MAX_REP 


States the value of the .variable 
Max_r ep . 




BASEST 


States status of base station. 




SCANJTIME 


States the length of a period 
(0-255 *100 ms) when the hand- 
held terminal scans other system 
channels . 

Default value: 30 (3 seconds). 




BAD_BASE 


Used by the roaming algorithm. 
0-255 dBuV. Default value: 15. 




GOOD_BASE 


Used by the roaming algorithm. 
0-255 dBuV. Default value: 15. 




BETTER_BASE 


Used- by the roaming algorithm, 
u z jd ud. uerauxc vaxue: xu. 
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If any, they contain a list of 
system channels to be used in 
base station monitoring. A frame 
with a list containing new 
system channels completely 
overrides the previous frame. 
The channel list has the 
following format (as described 
in the MAIN DOCUMENT) : 



01 02 03 04 05 06 07 08 


09 10 11 12 13 14 15 16 

! 1 1 1 1 ! ! 


number of channels 


0 0 0 0 0.0 0 0 


17 32 


33 48 


channel $1 - UPFREQ 


channel #1- - DOFREQ 


49 - 64 
> i ii 


65 . 80 
ii ii 


channel #2 - UPFREQ 


channel #2 - DOFREQ 


81 96 
1 1 1 I I 


97 112 
1 I i i 


channel #3 - UPFREQ 


channel #3 - DOFREQ 


113 128 


129 144 

! ! - I I 


channel if 4 - UPFREQ 


channel #4 - DOFREQ 


145 leo 

1 1 1 ! 1 1 ! 1 1__ 11111,1 



PARITY 



The number of following blocks depends on the size of the 
list. The maximum number of channels in the list is stated 
in reference Rl-06. 

Continues with following block #2 on the nexc page. 



FOLLOWING BLOCKS 



FOLLOWING BLOCK #1 
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FOLLOWING BLOCK §2 



channel #5 - 


UPFREQ 


channel #5 - 


DOFHEQ 


33 


48 

1 1 


49 

i i 


64 

1 1 


channel #6 - 


UPFREQ 


channel #6 - 


DOFREQ 


129 


144 
i I 


145 


160 


channel #9 - 


UPFREQ 


PARITY 



FOLLOWING BLOCK #3 



II II 
channel #9 - DOFREQ 


channel #10 - UPFREQ 


33 48 
I 1 1 i 


49 64 


channel #10 - DOFREQ 


channel #11 - UPFREQ 
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<SVP>, SUBTYPE 4 
PRIMARY BLOCK 



- states the frequency of 
different channel types for 
hand-held terminals. 



01 02 03 22 23 24 
1 1 1 !... .lit 


25 26 27 28 29 30 31 32 
1 1 1-.- Ill i 


MOB 


00001111 


33 34 35 36 37 38 39 40 
1 1 ! i_ _J. 1 1 1 


41 42 43 44 45 46 47 48 
1 1 I I I i I 


PRIO MASK 


BLOCK 


49 50 51 52 53 54 55 56 
1 1 1... Illlt 


57 58 59 60 61 62 63 64 
L...1 .1 1 1,1 1 


SVPTYP 


CHATYP 


65 66 67 68 69 70 71 72 73 7.4 75 76 77 78- 7-9-80 
... i i i i i i i i i i i i i i i 


UPFREQ 


81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 ! 


DOFREQ 



97 98 99 100 



0 0 0 0 0 0 



0 0 0 0 0 0 



_1 I I J !_ 
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States the <SVP> subtype, value 00000100 
in this case. 

States the type of channel: 
Value : 

1 Local system channel opened 

2 Not used (ignore that order) 

3 Local system channel closed 
(return to previous system 
channel) 

4 Access channel opened 

5 Access channel closed 

Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

Frequency number for down frequency, i.e. 
the frequency on which BASE transmits. 



FOLLOWING BLOCK ■■ No following blocks in this type 

• of frame. 



Exhibit 2, p. 535 



25 











1056 


- A 296 


S084 Ue 










"90-05-11 "p~A3 [MTS15.1 


<SVP>, SUBTYPE 
PRIMARY BLOCK 


5 






- contains a list of terminal 
MAN that has messages stored 
in the network mailbox 




01 02 03 
i i 




22 


23 24 


25 26 27 


28 29 


30 31 32 
1 ' 






MOB 


0 0 0 


0 1 


111 






33 34 35 


36 37 
i 


38 


39 40 


41 42 43 
i i 


44 45 


46 47 48 






PRIO 


MASK 


BLOCK 






49 50 51 


52 S3 
i 


54 


55 56 


57 58 59 


60 61 


62 63 64 






SVPTYP 


0 0 0 


0 0 


0 0 0 






6-5 66 67 


68 69 


70 


71 72 


73 74 75 
1 1 I 


76 77 


78 79 80 






0 0 0 


0 0 


0 




0 0 


0 0 0 


0 0 


0 0 0 






81 82 83 


84 85 


86 


87 88 
i 


89 90 91 

....1 1 I 


92 93 
.._ 1 


94 95 96 
1 ' . 






0 0 0 


0 0 


0 




0 0 


0 0 0 


0 0 


0 0 0 






97 




1 




104 


105 


t 1 


112 
I 1 






0 0 0 


0 0 


0 




0 0 


0 0 0 


0 0 


0 0 0 






113 

L. 1 ' 


■ 1 ! 






120 
i 


121 

1 1 L 


1 1 


128 






0 0 0 


0 0 


0 




0 0 


0 0 0 


0 0 


0 0 0 






129 

i i i 








136 
1 


137 

i i i 


1 1 


144 






0 0 0 


0 0 


0 




0 0 


0 0 0 


0 0 


0 0 0 






145 

i i i 


1 1 






1 1 






160 






PARITY 




SVPTYP 








States the <SVP> subtype, value 
00000101 in this case. 
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Containing a list of terminal 
MAN that has been stored in the 
network mailbox. 



The number of following blocks deoends on the size of the 
list. 

Continues with following block #2 on the next page. 



Exhibit 2, p. 537 



j 1056 - A 296 6084 Ue 

| "90-05-11 ' "?A3 [ MTS15.1 

FOLLOWING 3L0CK £2 




etc. 
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<SVP>, SUBTYPE 6 



PRIMARY BLOCK 

01 02 03 



• contains the timing parameters 
used in synchronization and 
message transactions 



0 1111 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 ■ 



49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 



CYCLE-TIME 



TIME— TO— NEXT 



TRANSACTION-TIME 



000 0 000000000000 



0000000000000000 



0000000000000000 



000 0 000000000000 



_! 1 ! ! ! !_ 
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CYCLE-TIME 



TIME-TO-NEXT 



TRANSACTION-TIME 



States the <SVP> subtype, value 
00000110 in this case. 

States the cycle time between 
two OPERATING states (0-255 x 
250 ms). 

States the time to the next 
<SVP6> frame (0-255 x 250 ms). 

States the time the terminal 
should stay in OPERATING state 
after 1) reception of a message 
from the network and 2) 
transmission of a message to the 
network (0-255 x 250 ms). 
Default value: 80 (20 seconds. 
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FOLLOWING BLOCKS 



FOLLOWING BLOCK SI 



Containing a lisb of terminal 
MAN or group MAN that are going 
have down-link traffic during 
this sweep cycle. 



3 



The number of followina blocks depends on the size of the 
list- 
Continues with following block #2 on the next page. 
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FOLLOWING 3 LOCK #2 

01 24 



MAN 7 1 


25 

1 1 


MAN 8 


48 


49 

i i 




72 


MAN 9 J 


73 

... I I .. . 




96 




MAN 10 




97 




120 


MAN 11 | 


121 




144 


MAN 12 | 


145 

1 1 




160 




PARITY 





etc. 
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5 ADDITIONAL MPAK - NETWORK LAYER 



A new MPAK is included for terminals using the battery 
saving protocol. The MPAK is used to inform, the network 
that the terminal has changed from battery saving mode to 
operate as a normal mobile terminal and vice versa. 

The new MPAK is within the packet class DTESERV (3) and 
has the packet type = 24. 



MODE (mode information) : 

Designated sender; 

The hand-held portable terminal. 

Designated addressee: 
The network. 

Raised flags: 
No raised flags. 

Criteria for generating the packet: 

When hand-held portable terminal changes from the battery 
saving protocol to operate as a mobile terminal this 
packet is used to inform the network. 

The same packet is sent to the network, but with a 
different mode identifier, when the terminal enters the 
battery saving protocol from being operating as a mobile 
terminal. 
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The network's normal action when receiving the packet: 

The network registers how the terminal operates, and 
forwards down-link traffic to the terminal in accordance 
to this. If terminal is using the battery saving protocol, 
the terminal is addressed in the TRAFFIC LIST. 

If the terminal is operating as a mobile terminal the 
network sends traffic immediately to the terminal. 



The terminal's normal action when receiving the packet: 
The terminal does not normally receives this packet. 



Length of the packet: 
9 octets. 
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MODE as generated by the terminal : 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



sender: the terminal 



addressee : the Mobitex Network 



0 0 0 0 



110 0 0 



TYPE DEPENDENT COMPONENT 
octet 9 : 



mode identifier 



mode identifier : 

0 = mobile terminal operation 

1 = battery saving protocol operation 
2-255 = reserved 
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6 DESIGN RECOMMENDATIONS 



Manual selection of Battery saving operating mode - Mobile 
terminal operating mode 



When the hand-held terminal is mounted into a battery 
charger in a car for example, it is recommended that 
terminal leaves the battery saving protocol operation and 
operates as mobile terminal. In chat case the user or the 
terminal itself initiates the transmission of the MPAK 
MODE to the network. The MPAK MODE will then identify the 
operating mode the terminal uses. 



Automatic change to mobile terminal operation. 

If the terminal could not find any signalling required for 
the battery saving protocol operation (<SVP6>), but 
detects <SVP1> required for mobile terminal operation, the 
terminal could act as mobile terminal. The user should be 
informed of this so the terminal could be switched-of f . 

The MPAK MODE is sent to the network informing that the 
terminal has gone into mobile terminal operation. 



Prevention from automatic quick channel monitoring 

In order to prevent the automatic quick channel monitoring 
from continuously running or to prevent the terminal from 
repeated attempts to go into the quick channel monitoring, 
it is recommended that the user manually can switch the 
quick channel monitoring function off. 

It is also recommended that the terminal has some kind of 
watchdog function implemented, limiting the operating time 
in quick channel monitoring mode. 



Manual initiation of quick channel monitoring 



If the hand-held terminal is implemented without automatic 
quick channel monitoring functions it is recommended that 
this function can be manually initiated. 
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User notification o£ 'lost contact' 



When the terminal loses contact with network, according to 
roaming procedure, and goes into quick scan monitoring the 
operator of terminal should be notified. It is also 
suitable if the received signal strength indication (RSSI) 
is displayed to the user so positioning of the terminal 
could be facilitated. 



RSSI when transmitting 

It is recommended to display the received signal strength 
to the user especially when the terminal is going to 
transmit, so the user can move the terminal to a good 
location. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the Dage(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 21 
Rl-09, 6 

Rl-16, 10, 11, 12, 13, 18 



Below are the reference designations listed. 

Reference Section 

R1 ~ 01 Arrangement of the documents 

Rl-0 2 MOBITEX System description 

R1- 03 • General description of terminals 

Rl-04 Terminology 

R 1-QS References 

R1 ~ 06 Network operator information 

Rl-08 Application layer 

R l-09 Network layer 

R1-11 Interface requirements, fixed terminals 

R1 ~ 12 Other requirements, fixed terminals 

R1 ~ 16 Link layer, mobile terminals 

R1 ~ 17 Physical layer, mobile terminals 

R1 ~ 18 Radio equipment, mobile terminals 

Other interfaces, mobile terminals 

R1 ~ 20 Other requirements, mobile terminals 
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MOBITEX 

Data Link Layer, Mobile Terminal 
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ABSTRACT 

This document specifies the data link layer for terminals 
connected to the MOBITEX network. 

The mobile terminal's Data Link Layer together with the 
Physical Layer form a radio protocol for communication 
between mobile- stations (MOB) and a base radio station 
(BASE) . 

The interchange of information between BASE and MOB is in 
the form of frames. There are 21 different types of 
frames. 

A number of different access strategies are used in the 
protocol to permit the handling of a large number of 
mobile terminals on a few trunked channels. The most 
important aspects are: 

Time slots 

Selective repetition 
Priority access 
Concurrent channels 
- Automatic roaming. 

To achieve high transmission reliability, the frames are 
divided into blocks where each block is coded. 



Htprod 
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The Link Layer of mobile terminals forms a link between 
the Network Layer and the physical radio channel with its 
special properties. It ensures a safe and efficient 
transmission path between the mobile terminal and the 
network, represented by the base stations. The Link Layer 
includes error correction facilities,, access algorithms, 
roaming algorithms, priority facilities etc. 
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2 INTERACTION WITH UPPER LAYERS 

The upper layers handle packets of information, MPAK . The 
following figure presents the general apperance of an MPAK 
(it is fully described in reference Rl-09). 



Type, status etc. 



Type-dependent 
component 



The Link- Layer transmits the MPAK in the form of 'a frame. 
The frame structure is defined in chapter FRAME STRUCTURE . 
The conversion .of a packet into a frame is described in 
APPENDIX A. 

If the Link Layer is unsuccessful in transferring an MPAK 
to the network, it is returned to the Network Layer, with 
this information. The Network Layer can then request a new 
attempt by sending the MPAK back to the Link Layer. 



AJS2JW3 
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3 . 1 PARTS OF THE FRAME 

The transmission of digital information over the radio 
channel is performed by transmitting frames. A frame 
• comprises a limited number of bits which are _ transmitted 
in an uninterrupted sequence. The frame consists of the 
following parts: 



sync pattern, base identity 



MOB address etc. 



Parity field . 



Information field 



Parity field 



Information field 



Parity field 



Frame head 
Primary block 



Following block #1 



Following block #n 



The frame head is described in detail in reference Rl-17. 
The information and parity fields of the following blocks 
are described in APPENDIX A, together with the primary 
block. 
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3.2 FRAME TYPES 



There are 21 different frame types: 

Name D esignation Transmitted by 
a BASE MOB 



l 


H frame 


<MRH> 


Yes 


Yes 


2 


Acknowledgement 


<ACK> 


Yes 


Yes 


3 


Negative acknowledgement 


<NAK> 


Yes 


Yes 


4 


Repetition request 


<REB> 


Yes 


Yes 


5 


Repetition reply 


<RES> 


Yes 


Yes 


6 


Access request, data 


<ABD> 


No 


Yes 


7 


Access request, speech 


<ABT> 


No 


Yes 


8 


Access request, emergency 


<ABL> 


No 


Yes 


9 


Access permission, data 
Access permission, speech 


<ATD> 


Yes 


No 


10 


<ATT> 


Yes 


No 


11 


Access permission, emergency 


<ATL> 


ires 


No 


12 


Change channel, data 


<BKD> 


Yes 


No 


13- 


•Change channel, speech 


<BKT> 


Yes 


No 


14 


Free signal 


<PRI> 


Yes 


No 


15 


Sweep' signal 


<SVP> 


Yes 


No 


16 


Silence order 


<TST> 


Yes 


No 


17 


Activity request 


<AKT> 


Yes 


NO 


18 


No access permission, speech 
Change base station, speech 
Wait for channel, speech 


<NAT> 


Yes 


NO 


19 


<BBT> 


Yes 


NO ■ 


20 


<VKT> 


Yes 


NO 


21 


Cancel access request, speech <AAT> • 


No 


Yes 
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The following pages give a brief description of each frame 
type. Refer to Appendix A "Frames" for a complete 
definition of frame types. 



An <MRM> is used to transfer packets (MPAKs). The 
packet formats are defined in reference Rl-09. 



Acknowledgement <ACK> 

An <ACK> acknowledges a correctly received frame. 

<ACK> indicates that all blocks in the frame have 
been correctly received. It includes the sequential 
number of the received frame. 

Negative acknowledgement <NAK> 

A <NAK> requests repetition of the entire <MRM>. 

<NAK> indicates that the primary block has been 
correctly received, but that the following blocks 
have been lost. It contains the sequential number of 
the received primary block. <NAK> results in a 
complete repetition of the lost <HRH>. 

Note that if the number of blocks in <MRM> was 3 or 
more, <REB> is used instead of <NAK>. 



Repetition request .. <REB> 

A <REB> requests repetition of erronous blocks in an 
<MRM> or <RES>. 

If it is found during reception that certain blocks 
in a frame are not correct, a request far these 
blocks to be repeated can be made by transmitting a 
<REB> . The request contains a bit map of the blocks 
to be repeated. This bit map refers to the original 
<MRM>, even during a sequence of repetitions. 

<REB> contains the sequential number of the received 
<MRH> and results in a <RES>. 

Note that if the number of blocks in <MRM> was 2 or 
less, <NAK> is used instead of <REB>. 
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Repetition reply <RES> 

A <RES> is the reply to a <REB>. 

<RES> is a selective repetition of blocks from an 
<MRH>. The following blocks of the <RES> contain 
copies of blocks according to the bit map of the 
<REB>. <RES> contains the sequential number of the 
original <MRM>. 



6 Access request, data <ABD> 

An <ABD> is a request to transmit an <MRM>, 
containing "data" {defined in chapter "Addressing a 
mobile terminal"), whose length (number of blocks) 
exceeds the value of MAX_ACCESS. MAX_ACCESS is 
described in chapter "Time division"? 

If the length of the <MRM> exceeds MAX_ACCESS, 
access must be requested before the <MRM> may be 
sent. 

The <ABD> states the number of blocks in the 
corresponding <MRM>. 



7 Access request, speech <ABT> 

An <ABT> is a request to transmit an <MRM>, 
containing "speech" (defined in chapter "Addressing 
a mobile terminal"), containing a request for a line 
connection whose length (number of blocks) exceeds 
the value of MAX_SPEECH. MAX_SPEECH is described in 
chapter "Time division". 

If the length of an <MRM> with a connection request 
exceeds MAX_SPEECH, access must be requested before 
the <MRM> may be sent. 

The <ABT> states the number of blocks in the 
corresponding <HRH>. 
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Access request, emergency <ABL> 

An <ABL> is a request to transmit an <MRH> 
containing an "emergency" (defined in chapter 
"Addressing a mobile terminal"), whose length 
exceeds the value of MAX_ACCESS. HAX_ACCESS is 
described in chapter "Time division". 

If the length of the <MHM> exceeds MAX_ACCESS, 
access must be requested before the <MRM> may be 
sent. 

The <ABL> states the number of blocks in the 
corresponding <MHM>. 



Access permission, data <ATO> 

BASE replies with an <ATD> to an <ABD> from a MOB, 
when BASE is ready to accept an <MRM>. 

When permission is granted (<ATD> received), MOB is 
expected to transmit an <MHM> containing a data 
packet. 



Access permission, speech <ATT> 

BASE replies with an <ATT> to an <ABT> from a MOB, 
when BASE is ready to accept an <MRM>. 

When permission is granted (<ATT> received), MOB is 
expected to transmit an <MRM> containing a request 
for line connection. , 



Access permission, emergency <ATL> 

BASE replies with an <ATL> to an <ABL> from a MOB, 
when BASE is ready to accept an <MHM>. 

When permission is granted (<ATL> received), MOB is 
expected to transmit an <MRM> containing an 
emergency signal. 
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Change channel, data <BKD> 

A <BKD> orders a MOB to another channel in order to 
transmit or receive an <:MRM>, data or emergency. 

Normally the terminal returns to the original 
channel when the <MHM> has been transmitted or 
received. If an error occurs on the assigned channel 
then MOB returns to the original channel after a 
timeout period stated in the <BKD>. 



13 Change channel, speech <BKT> 

A <BKT> orders a MOB to another channel in order to 
transmit or receive an <MRM> containing a request 
for line connection. 

Normally the terminal returns to the original 
— channel when the' line connection is over. If an 
error occurs on the assigned channel then MOB 
returns to the original channel after a timeout 
period stated in the <BKT> . 



14 Free signal <FRI> 

BASE transmits a <FRI> when it is ready to handle 
traffic from MOB. 

A free signal precedes a free cycle. A free cycle is 
a period of time .when all of, or parts of, the total 
fleet of mobile terminals are collectively permitted 
to transmit. 



15 Sweep signal <SVP> 

The sweep signal is a periodically recurring signal 
from BASE. An <SVP> is transmitted by BASE for two 
reasons: 

1 <SVP> marks the start of a sweep cycle. 

2 <SVP> contains system parameters, such as: 

' - time to next <SVP> 

- maximum number of repetitions' 

channel list 
local system channel 
access channel 
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Silence order <TST> 

Silence order is used by BASE to withdraw all access 
permissions during a free cycle. A MOB that is 
already transmitting may continue to do so, but for 
every other MOB the access permissions for all 
traffic types- (emergency, speech and data) are 
withdrawn. 

Note: Please also refer to the description of the 

silence signal in reference Rl-17. This signal 
has the same meaning as the <TST>-£rame but 
uses only the frame head and thus addresses 
ALL mobile terminals. 



Activity, request <AKT> 

An <AKT> is used by BASE to check whether a certain 
MOB is active. MOB replies with. an <ACK> to such _a 
frame. 



No access permission, speech <NAT> 

BASE replies with <NAT> to an <ABT> from a MOB when, 
■for some reason, a line connection cannot be set up 
(e.g. no channel is available). 



Change base station, speech <BBT> 
BASE will use <BBT> 

- as a response to an <ABT> when another base 
station is. to be used for the line connection 
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Wait for channel, speech <VKT> 

If no channel is immediately available, BASE may 
place MOB in .a queue of waiting calls and reply with 
a <VKT> to a received <ABT> . When a speech channel 
becomes available, BASE indicates this by 
transmitting a <BKT> to MOB- If there is no free 
channel within reasonable time, BASE ends the 
session by transmitting a <nat>. 



21 Cancel access request, speech <AAT> 

After having received a <VKT> from BASE, the mobile 
terminal may end the session by transmitting an 
<AAT>. 
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4 TRAFFIC HANDLING 

4.1 TRANSMISSION PRINCIPLES 

Transmission is carried out through the interchange of 
frames between MOB and BASE. Different types of trans- 
mission cases demand different behaviours by the units 
involved. Some of the problems considered in this chapter 
are: 



Access to the channel 



Keeping contact 
with the network 



Addressing 



Sequential numbering 



• describes how a small number 
of channels can handle 
concurrent traffic from a 
large number of subscriptions 
at the same time. 

■ describes how the mobile 
unit maintains its contact 
with the network (roaming). 

• describes how the addressing 
of base radio stations, 
terminals and subscriptions 
take place. 

■ describes how repeated 
presentations of repeated 
frames ace avoided. 
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4.2 ACCESS TO THE CHANN 


EL 


4.2.1 Time division 





A MOB, with traffic to send, is allowed to establish 
contact with the base radio station in special free 
cycles. These cycles are initiated by BASE by transmitting 
a <FRI>. 

This frame contains an indication of the length of the 
free cycle, including the following parameters: 

Slot_length States the length of each individual free 
slot. 

Pree_slots States the total number of free slots in 

the current free cycle. 

Rand_slots States the interval for" the random number 

generator in the MOB. 

Max_access States the maximum length of an <MRM>- 

frame, containing data or emergency, which 
can be sent without a preceding access 
request. 

Max_speech States the maximum length of a frame, 

containing a connection request, which can 
be sent without a preceding access 
request. 

In order to reduce the probability of a collision between 
traffic from several mobile units, the free cycle is sub- 
divided into slots. The length of these slots (Tl) are 
stated by the Slot length parameter. 



slot n+1 slot n+2 slot n+3 



By the aid of an internal clock, the mobile terminal is 
able to detect slot boundaries. The definition of how slot 
boundaries are calculated is found in reference Rl-17. 
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The following happens in the free slots. 

1 Traffic initiated before the start of the free cycle 
must be distributed at random. A random number 
generator selects a slot between 1 and Rand slots. 
Transmission begins at the start of the selected 
slot. 

2 Traffic initiated during che free cycle is sent at 
the beginning of the next slot. 

3 if the <HHM> to be sent is longer than MAX ACCESS or 
MAX_SPEECH, a request for access must be made. The 
transmission of this request is done according to 
rules 1 or 2 above. 



If the Data Link Layer is in the speech mode (ordered by 
the Network Layer), an <MRM> may be sent immediately. This 
is done independently of any free cycles. 



WJ9JS15W 



Exhibit 2, p. 564 



Cantel Mobitex- 



9/1056 - A 296 5171/02 Oe 



1990-02-26 A 



4.2.2 Mobile fleet division 

The access permission in the free cycle can be given to 
parts (subsets) of. the mobile fleet according to the 
setting of corresponding fields in the free signal, <FRI>. 
This is used to reduce the number of access attempts in a 
free cycle. The following principles are used: 



Masked addressing 



Priority 



Traffic type, FFG 



The address and mask fields in <FRI> 
are used for. a binary division (1, 2, 
4, 8 etc) of the mobile fleet. 

Is used to give access only to mobile 
terminals above a stated priority 
level. 

Is used to give access only for stated 
traffic types (emergency, data or 
speech ) . 



In the <SVP> a channel (receiving and transmitting 
frequencies) and a channel type (local system or access 
channel) can be given. By using the addressing facilities 
in the <SVP> it is possible to assign a certain system 
and/or access channel to the whple mobile fleet or to 
parts of it. 

The local system channel is used in much the same way as 
any other system channel. It is not shared by surrounding 
base stations and may thus be used without interference 
from these. 

When assigned a local system channel, the mobile terminal 
monitors this channel until further notice or the roaming 
algorithm indicates that it is no longer usable. 

When assigned an access channel, the mobile terminal must 
use this channel when it. has an <MRM> to transmit. The 
access rules described above also apply to this channel. 
After the. <MHM> has been acknowledged the terminal returns 
to the previous (local) system channel. 
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The algorithm for selection of a suitable base is called 
roaming. It is designed to handle a nationwide system of 
base radio stations on different system channels, with 
either frequency or time division in their signalling. The 
algorithm includes two methods of channel monitoring: 
normal and quick. 

A mobile terminal measures the received signal strength 
from all base radio stations. To evaluate one base station 
the mobile terminal calculates its roaming value. The 
roaming value is defined as the average received signal 
strength. Please see reference Rl-17 for further 
information about how to measure received signal strength. 

After a <BKT> -or a <BKD> has been received, the monitoring 
is disabled. It is resumed after the connection/session is 
ended, and the same table of evaluations as before the 
connection is used. 

When the terminal is switched on, it uses the 
CURRENT_SYSTEM_CHANHEL and the CDRRENT_BASE until this 
base becomes unsuitable according to the roaming 
algorithm. If no CDRRENT_BASE has been stored, the 
terminal immediately starts the quick channel monitoring, 
using the default list of system channels. 



Lists of system channels 

The mobile terminal uses a list of system channels when it 
monitors the base radio stations or searches for a new 
base. It is either a permanent or a temporary default list 
(please refer to the chapter 'SYSTEM PARAMETERS TO BE 
STORED IH THE TERMINAL' and to reference Rl-06) or the 
current list (stated in the <SVP>-f rame) . 

The default list is used until a <SVP>-frame has been 
received. A <SVP>-frarae with a new list of system channels 
completely overrides the old current list. 

The default list is also used in the quick channel 
monitoring after an unsuccessful search of the current 
list has been made. Again, the default list is used only 
until a valid <SVP>-frame with the current list of system 
channels has been received from the new base station. 
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Measurement methods 

When the mobile terminal measures the received signal 
strength it can use two different measurement procedures: . 
FRAME or CONTINUOUS. Which of these it should use is 
stated by the parameter RSSI_PROC in the <SVP>-f rame. 

If RSSI_PROC states FRAME the mobile terminal measures the 
received signal strength of the frame heads received 
during the RSSI_PERIOD (stated in <SVP>). 

If RSSI_PROC states CONTINUOUS the mobile terminal 
measures the received signal strength during the entire 
RSSI_PERIOD. 

The parameter RSSI_PERlOD includes channel switching time, 
and has the default value 2 960 ms, with a tolerance of 
+/- 10 ms. 

During monitoring of current system channel and when 
making the final decision before chosing a new base, the 
terminal measures average received signal strength during 
the reception of frame heads. 
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Normal channel monitoring 

A mobile terminal measures the received signal strength 
from base radio stations on the CURRENT_SYSTEM_CHANNEL and 
calculates a roaming value for each base station. 

During each <SVP>-cycle (i.e. the time between two <SVP>- 
frames) the terminal leaves the CURRENT_SYSTEM CHANNEL for 
' a predefined period to monitor other channels and then 
return. These channels are chosen from the list of system 
channels (default or current). The start of the scan 
period depends on the terminal's own subscription number 
(MAN) being odd or even: 

scan start(odd) = TIME_TO_NEXT - 10ms -' 2*SCAN TIME 
scan start (even) * TIME_TO_NEXT - 10ms - SCAN TIME 



SCANJTIME = Length of predefined scan period, including 
_ ,.,...„ channel switching time. This is stated in 

the <SVP>-frame and has. the default value 3 
seconds, with a tolerance of +/- 10 ms.. 

TIME_TQ_NEXT = Interval between two <SVP>-f rames. This 

parameter is stated in the <SVP>-frarae and 
has the default value 10 seconds. 



ch #n : : let- 
ch #4 — — — Hri— 

ch #3 -Hrl 

ch #2 —Hrl 

ch #1 —Hrl 



where m = monitor current system channel 

s = scan other system channels 
r = RSSI_PERIOD 
e = evaluation 

The monitoring is cyclically repeated for all channels and 
every channel is monitored one RSSI_PERIOD. 

For example, if the RSSI_PERIOD and SCANJTIME have default 
values, the list contains 7 channels and the length of a 
<SVP>-cycle is 10 seconds, then the time between the scans 
of a specific channel from the list is 70 seconds. On the 
other hand, if the RSSI PERIOD is 4 (80 ms) and SCANJTIME 
is 30 (3 s) then the moEile will scan at least 30 channels 
during each <SVP>-cycle. 
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Criteria for leaving CDRR 


ENT BASE 



The mobile terminal leaves CURRENT BASE during a <SVP>- 
cycle if: ~ 

-1- roaming value (CURRENT_BASE) < BADJ3ASE 

BAD BASE is stated in the <SVP>-frame and its 
default value is 15. 

or 

-2- roaming value (best base) > 

roaming value (CDRRENT_BASE) + BETTER_BASE. 

If this criterion is fulfilled, the mobile should remain 
in normal channel monitoring on the current system channel 
for another <SVP>-cycle. During the next scan period the 
mobile should measure the average received signal strength 
of frame heads from best base. If the roaming value still 
fulfils the criterion, the mobile should select this base' 
as new CURRENTJBASE and the new channel as 
CURRENT_SySTEM_CHANNEL . 

The following figure shows an example where this criterion 
applies: 

roaming value 

best base 



CDRRENT_BASE 



30 

BETTER__BASE | 
BAD_BASE 15 



The parameter BETTER_BASE is stated in the <SVP>- 
frarae and its default value is 10. 
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The following criteria cause the mobile .to leave 
CORRENT_BASE immediately without waiting for the end of 
the <SVP>-cycle: 

-3- The terminal has made MAX_REP retransmissions 

without getting an acknowledgement from base. The 
value of MAX_REP is stated in the <SVP>-frame. 

-4- The terminal has received a <NAT> (including an 
order to leave the CURRENT_BASE) from base. 

And the last criterion applies when no traffic is 
exchanged: 

-5- The terminal has not received valid <SVP>- f rames 
within 2 <SVP>-cycles (= 2*TIME_TO_NEXT) . 



Any of the above criteria, except -2-, causes the mobile 
terminal to leave CURRENTJBASE and evaluate other bases.. 



Evaluation of other base stations 

MOB first evaluates the best base {? CURRENT_BASE) from 
the normal channel monitoring. This is done by evaluating 
the: 

roaming value from the last <SVP>-cycle (on 
CURRENT_S YSTEM_CHANNEL ) 

roaming value from the last RSSI_PERIOD of a 
specific channel (on the other system channels) 

If the base is on the CURRENT_SYSTEM CHANNEL and have a 
roaming value greater then GOOD_BASE it can be directly 
selected as CURRENT_BASE . 

But if the new base is on. a new system channel the mobile 
shall measure the average received signal strength during 
the reception of frame heads on this channel for 
SCAN_TIME. If the measured roaming value is greater then 
GOOD BASE, the mobile should select this channel as 
CURRENT SYSTEM CHANNEL and this base as CURRENT_BASE. 
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Quick channel monitoring 

If best base is not good enough, a quicker scanning 
procedure is adopted until a suitable base is found. MOB . 
then scans its list of (current) system channels in the 
fallowing way: 

-1- Begin with the first channel from the list. 

• -2- Measure the average received signal strength for 
RSSI_PERIOD. 

-3- If the measured roaming value is greater than 

GOOD_BASE remain on this channel. Otherwise skip to 
step 6. 

-4- Measure the average received signal strength during 
the reception of frame heads on this channel for 
SCANJTIME. 

-5- ..If the roaming value is greater then GOOD_BASE 

select this channel as CORRENT_SYSTEM_CHANNEL , the 
base as CURRENT_BASE and return to normal channel 
monitoring. Otherwise go to step 6. 

-6- Stop scanning if all channels of the list have been 
scanned, otherwise choose next channel from list and 
repeat steps 2-5. 

After MOB has scanned a number of channels from the list 
(please see reference Rl-06) , or the list is ended, the 
current system channel is scanned in the same manner. The 
scan of the list is then resumed, if the end of the list 
was not already reached. 

If the complete current list of system channels has been 
searched without a new base having been chosen, the quick 
channel monitoring is restarted with the default list of 
system channels. 



Re-establishing contact 

When a new CURRENTJ3ASE has been chosen, an <MRM>-frame 
with roaming information is sent to it. If the new BASE is 
identical to the old CORRENT_BASE, an <MRM>-frame with 
activation information is sent instead. 
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Area identification 

The frame header (on the physical layer) includes an area 
identification used to specify geographical areas. Such an 
area is denoted as a traffic area and is given a unique 
area ID by the network. 

From the network layer, the data link layer receives a 
list including the areas subscribed to by the user. The 
list also shows if the areas not subscribed to are allowed 
to be used, with for example higher charges, or not. 

From the physical layer, the data link layer receives 
information about incoming roam information, i.e. area ID, 
base ID and weighted roaming value. 

During the roaming procedure (described above), the 
terminal will 'primarily evaluate roaming information from 
bases belonging to the subscribed traffic areas. If the 
terminal is allowed to traffic other areas all bases may 
—be considered in the roaming procedure. — 

In case a "non-subscribed" base is chosen (possible only 
in quick channel monitoring), it should be notified to the 
application layer, as well as when the terminal returns to 
a "subscribed" base. 

If the terminal have not yet received the list of area 
IDs, the roaming procedure will evaluate all base 
stations. 
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4 . 4 ADDRESSING 



4.4.1 Addressing the base radio station 

The base radio station is only addressed in the frame 
head. Further details can be found in reference Rl-17. 



4.4.2 Addressing a mobile terminal 

Transmitting The mobile terminal's, subscription number 
(MAN) is always used as the HOB address. 

Receiving When receiving, the MOB address refers to 

the mobile terminal's MAN, or any MAN 
representing a group to which the terminal 
- belongs. (A transferred subscription is 
addressed in the MPAK.) 

■ — A MAN -representing a group occurs only 

when receiving frame types <MRM>, <BKD>, 
<BKT>, <BBT> and together with, a mask 
value of 0 in frame types <PRI>, <SVP>, 
<TST>. Masked addressing is described in 
detail in chapter 4.4,2.1. 

Masked and priority addressing is used in 
frame types <SVP> and <TST>. 

Masked, priority and traffic type 
addressing is used in frame type <FRI>. 
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4.4.2.1 Masked addressing. 

Masked addressing is only used in <SVP>, <FRI> and <TST>. 
In this addressing mode both the MASK and MOB fields of 
the frame are used. The MASK field indicates the number of 
bits from the beginning of the MOB field (most significant 
bits) that should not be considered (masked out) when 
comparing the MOB field with the terminal's MAN. 

A MASK value different fromO (zero) indicates that only 
the terminal's own MAN is to be compared with the relevant 
bits of the MOB field. 

A MASK value of 0 {no bits masked out, all bits of MOB are 
relevant) indicates that the MOB field is to be compared 
with both the terminal subscription MAN and with the MANs 
of all current group numbers in the group list. 

The terminal is considered to be addressed if all relevant 
bits of the MOB field are the same as the corresponding 
-bits .•-o£-=one of the compared MANs. 

A MASK value of 24 (decimal) .indicates that all bits are 
masked out and that all mobile terminals are addressed. 

Note: For <SVP> and <TST> signals the priority of the 

terminal must also comply with that of the signal. 

For the <FRI> signal the priority and traffic type 
of the terminal must comply with that of the signal 
for the terminal to be addressed (except for 
emergency where priority is ignored). 
(See below) . 
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Example: Assume a frame with the following contents in the 
HOB and MASK fields. 




(x indicates that the corresponding bit is to be 
ignored) 




MOB Eield Bit no. : 
Value : 


1 24 
101000000000101010110010 




MASK field Bit no. 

Value 


: 15 

s 11000 (24 decimal) 




Addressed MAN Bit no. : 1 24 




Value : xxxxxxxxxxxxxxxxxxxxxxxx 
All mobile terminals are addressed. 




MASK field Bit no. 
=.,. . Value 


: 1 5 

: 10111- (23 decimal). 




Addressed MAN Bit no. : 1 24, 
Value : xxxxxxxxxxxxxxxxxxxxxxxO 




Only 'mobile terminal subscriptions with MAN 
ending with binary 0 are addressed. 




MASK field Bit no 
Value 


: 1 5 

: 10110 (22 decimal) 




Addressed MAN Bit no. : 1 xxxxxxxxxxxxxlO* 




Only mobile terminal subscriptions with MAN 
ending with binary 10 are addressed. 




MASK field Bit no 
Value 


5 1 5 

s 00000 (0 decimal) 




Addressed MAN Bit no.: 1 24 
Value : 101000000000101010110010 




The MASK value 00000 (zero) indicates that 
mobile terminals with the terminal 
subscription HAN, or any of its MAN numbers 
representing groups, identical to the MOB 
field are addressed. 
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4.4.2.2 Priority addressing 

Priority addressing is used in the frames <SVP>, <TST> and 
<FR1> . 

A terminal subscrir»tion belongs to one of 4 priority 
groups. The terminal may have two priority states within 
each group, normal or raised. The terminal will raise its 
priority if it has made MAX_REP retransmissions of the 
same frame without getting any acknowledgement from the 
base station. 

PRIQ field 



-rnr 

110 
101 
100 
011 
010 
001 
000 



Meaning 

Priority group 4, 



raised priority 
. normal 

Priority group 3, raised priority 
" * , normal 
Priority group 2, raised priority 
" , normal 
Priority group 1, raised priority 
" , : normal 



When receiving a frame with priority addressing, the 
mobile terminal is addressed if its own priority is higher 
than or same as the received priority. 

If the terminal is to transmit an emergency signal the 
priority level is ignored. 



A232S15M 
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4.4.2.3 Traffic type addressing 

Traffic type apniies to the type of MPAK to be sent from 
the mobile terminal. The packets are separated into 3 
traffic types: 

emergency: MPAK class PSOSCOM 

speech: MPAK class CSOBCOM 

data: All other types of MPAK 



Traffic type addressing is used only in the <FRI> frame. 
The traffic type to which the <FRI> applies is coded into 
the FFG field as follows: 



Value 


Emerqency 


Speech 


Data 


00 


yes 


no 


no 


01 


yes^— _ 


no 


yes 


10 


yes 


yes 


no 


11- 


yes 


yes 


yes 



Note: For the frames <SVP> and <TST>, both the masked 
address and the priority must be correct for the 
terminal to be addressed. 

For the <FRI> to be valid, the masked address, the 
priority and the traffic type criteria must be met 
by the terminal, except for the transmission of an 
emergency signal where only the masked address and 
traffic type criteria has to be met (priority is 
ignored) . 
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4.5 SEQUENTIAL NUMBERING 

The transmitting unit repeats the transmission of a frame 
if there is no response from the receiving unit. This 
means that the receiving unit can receive identical frames 
if its resnonse is not detected by the transmitting unit. 
To avoid repeated presentation of information, certain 
types of frame are given sequential numbers. The principle 
is as follows. 

The terminal sets up a sequential register for the 
terminal subscription MAN (up and down sequential 
number) and for each of the MANs stored in 
GHOOP_LIST (only a down sequential number for each). 

A sequential number is an integer with a value in 
the range (0...15). The sequential numbers are 
incremented cyclically 1, 2, 3...., 14, 1, 2, 3 etc. 
The values 0 and 15 are reserved for special 
purposes . 

- The utT^eWehtiaT number applies to frames 

transmitted in the direction from MOB to BASE. The 
up sequential number is increased by one by the 
mobile terminal for each new <MKM>-frame 
transmitted. 

MOB which receives a sequentially numbered frame 
checks the sequential number of the frame against 
the stored down sequential number for the 
corresponding MAN. If the received sequential number 
is the same (and not 0, see below), the information 
in the frame is ignored. If the sequential number is 
not the same (or 0, see below), the frame is 
accepted and the sequential number of the received 
frame is stored (except for 15, se below). The 
number is stored when acknowledgement of the frame 
has been sent. 

On reception, the value 0 for a sequential number 
means that a sequential number check should not be 
carried out on the frame and that the value 0 should 
be stored in the terminal as the new down sequential 
number . 

On reception, the value 15 for a sequential number 
means that a sequential number check should not be 
carried out on the frame and that the old down 
sequential number remains. 
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The up and down sequential numbers are set to 0 when not 
defined (e.g. at initial start up). 

Down sequential numbers for group numbers are reset to 0 
when roaming in on a new base station. 

Also returned packets with status DNKNOWN should have a 
sequential number. 

When the mobile is transmitting the following types of 
packets, the sequential number 15 should be used: 

CSUBCOM:DISCON 

CONREA 
DTESERV: ACTIVE 

INACTIVE 

ROAM 
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4.6 OUTPOT POWER CONTROL 

The MOBITEX system allows for mobile terminals to control 
the output power via oarameters in the system signalling, 
from the base radio station. Network operator requirements 
concerning this matter is stated in reference Rl-06, as 
well as the nominal output power. 

Requirements, such as the number of output levels to be 
controlled by the mobile terminal and in what steps the 
levels should be controlled, is also stated in reference 
Rl-06. 

The mobile terminal receives information about the output 
power to be used in the base station cell in question. 
This is stated by the parameter TXPOW in the <SVP>-frame. 

Portable transmitters may have lower output power than 
ordinary transmitters. Note that the receiver sensitivity 
should be reduced or an offset should be added to the 
parameters GOOD BASE and BAD_BASE used m the roaming 
procedure. This~is done in order to keep the same ratio 
between the permitted transmission losses in the send and 
receive directions, i.e. to maintain a balanced radio 
path. 

For example, if the power of the transmitter is 10 dB 
lower than the specified level, the receiver sensitivity 
could be reduced by 10 dB from the specified sensitivity 
level. Instead of reducing the sensitivity, an offset of 
10 can be added to the parameters GOOD_BASE and BAD_BASE. 



A292S13M 



Exhibit 2, p. 580 



Cantel Mohitex~ 



9/1056 - A 296 5171/02 De 



1990-02-26 A 



4.7 LOGICAL DESCRIPTION 

The data flow diagram below shows the interaction between 
modules in the Data Link Layer and between this layer and 
the Network and Physical Layers. 



[Application Layer { 



Network Layer 



Packet handling (PAHA) 



1 






1 


i 


Processing -in- 
coming frames 
(IFRA) 




Processing out- 
going frames 
(OFRA) 
















7 i 














Input and 
decoding- (DCOD) 




Coding and 
output (CODE) 


Base contact 
monitoring 


3 ' 














' 4 ' 


' 5^ 


' 6 < 


1 7 



Physical Layer 



-1- MPAK transmitted, MPAK not transmitted, HPAK received, 

roaming, activation 
-2- MPAK to transmit, MPAK to retransmit, speech on, 

speech off, order to return MPAK, list of area IDs, 

list of group numbers 

Signals to/from Physical Layer: 

-3- Received block, Sync search 
-4- Frame to send, Frame length 

-5- Slot length, Chosen slot. Slot reached. Silence, 

Cannot send 
-6- Current base, Frame sent 
-7- Received base, Measure_RSSI, RSSIjneasured 

Signals to the Application Layer: 

-8- Speech queue info, base lost, base contact, area 
subscribed to chosen, area not subscribed to chosen 
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4.7.1 Input and decoding (DCOD ) 

DCOD converts the bit stream from the physical layer into 
frames. It decodes the blocks of these frames and checks 
that the frames are addressed to the terminal. 



4.7.1.1 Logical description 



wait for information bits from Physical Layer 
read and decode first block 
IP first block is correct THEN 
CASE frame type 

WHEN <ACK> , <NAK> , <ATL> , <ATD> , <ATT> , £NAT > or <VKT> 
IF frame address ■. terminal address THEN 

send frame to OPRA 
ENDIF 
WHEN <REB> 

IF. frame address = terminal address THEN 
read and decode remaining blo cks of frame 
IF frame is error-free THEN 

send frame to OFRA 
ENDIF 
ENDIF 

WHEN <FRI>, <SVP> or <TST> 

IF (frame address with mask = terminal address) OR 
(mask=0 and address » a group address) THEN 
read and decode remaining blo cks of frame 
IF frame is error-free THEN 

send frame to OFRA 
ENDIF 
ENDIF 

WHEN <AKT> or <RES> 

IF frame address = terminal address THEN 

read and decode remaining blocks of frame 

send frame to IFRA 
ENDIF 

WHEN <MRH>, <BKD>, <BKT> or <BBT> 

IF (frame address = terminal address) OR 
(frame address = a group address) THEN 
read and decode remaining blocks of frame 
send frame to IFRA 
ENDIF 
ENDCASE 
ENDIF 

send sync_search order to Physical Layer 



a.prM. 



ASMS1SM 
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4.7.2 Processing incoming frames (IFRA ) 

IFHA handles the received frames from DCODi If a received 
<MHM> is not error-free, IFHA requests a repeat 
transmission of the faulty blocks until a correct <MRM> 
has been received and acknowledged. 



4.7.2.1 Logical description 



wait for frame from DCOD 
CASE frame type 
WHEN <MRM> 

IP we have <MRM> waiting for <RES> THEN 
delete that <MRH> 

ENDIF 

IF response required THEN 

IF <MRM> is error-free THEN 

create <ACK> and send it to CODE 

send <MRM> to- 5 AHA 
ELSE 

IF <MRM> is shorter .than 3 blocks THEN 

create <NAR> and send it to CODE 
ELSE 

create <REB> and send it to CODE 
store <MRM> while waiting for <RES> 
ENDIF 
ENDIF 
ELSE 

IF <MRM> is error free THEN 
send <HRM> to PAHA 

ENDIF 




retrieve stored <HRM> 

IF sequenti al n umber = stored <MRM>:s sequential 

number THEN 
complete <MRM> with error fre e blocks from <RES> 
IF <MRM> is error free THEN 

create <ACK> and send it to CODE 

send <MRM> to PAHA 
ELSE 

create <REB> and send it to CODE 
store <HRM> while waiting for <RES> 
ENDIF 
ENDIF 

WHEN <BKT>, <BKD> or <BBT> 
IF frame is error free THEN 
• send frame to PAHA 
ENDIF 
WHEN <AKT> 

create <ACK> and send it to CODE 
ENDCASE 
ENDLOOP 
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4.7.3 Processing outgoing frames (OFRA) 

OFRA handles the sending of frames. It must wait for 
permission to send,, decide whether an access request is to 
be sent first etc. 

OFRA receives <MRM>-f rames of traffic types emergency, 
speech or data from PAHA. It returns them co PAHA with a 
statement of whether acknowledgement of the frame has been 
received or not. PAHA can also request that OFSA should' 
cease trying to transfer the frame. 

If the Data Link Layer is in speech_mdde, an <MRM> may be 
sent immediately. This is done with a timeout that is 
independent of any free cycles. 

OFRA is capable of handling only one <MRM>- frame at a 
time. 



.4.7.3.1 



Logical description. 



LOOP 

wait for input signal 

CASE -input signal 

WHEN new <MRM> from PAHA 

IF (free cycle is running) and {priority and traffic 
type allows transmission) THEN 
choose next free slot 

store <MRM> while waiting for slot_reached 
ELSE 

IF speechjmode THEN 

send copy of <MRM> to CODE for transmission 

speech mode timer := 2 seconds 
ELSE 

store <MRM> while waiting for permission to send 
END IF 
ENDIF 

cancel_request := FALSE 

WHEN STOP_SEND from PAHA 

return <MRM> to PAHA with status 'discontinued' 
IF speech_queue THEN 

IF free cycle is running THEN 

choose next free slot 
ENDIF 

speech_queue := FALSE 
cancel_request := TRUE 



IHEN SPEECH_TRDE from PAHA 
speech_mode := TRUE 
speechjgueue := FALSE 

HEN SPEECH_FALSE from PAHA 
speechjnode := FALSE 
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WHEN timeout of speech_mode_timer 

return <MRM> to PAHA with status 'failed' 

WHEN <ACK> from DCOD 

IF sequential num ber in <ACK> = sequential number in 
latest <MRM> THEM 

return <MRM> to PAHA with status 'OK' 
disable speech mode timer 
ENDIF 

WHEN <NAK> from DCOD 

IF sequential num ber in <NAK> = sequential number in 
latest <MRM> THEN 
send copy of latest <MRM> to CODE for transmission 



HEN <REB> from DCOD 
IF sequential number in <REB> = sequential number in 
latest <MRH> THEN 
create <RES> and send it. to -CODE for .transmission 



HEN <FRI> from DCOD 
update free signal parameters 
IF we have <MRM> waiting for <RES> THEN 

delete that <MRM> 
ENDIF 

IF cancel request THEN 

choose a~random free slot 
ELSE 

IF we have <MRM> to send THEN 

IF priority and traffic type allows transmission 
THEN 

IF NOT speech queue THEN 

IF we have alr eady repeated <MRM> MAX_REP 
times THEN 
return <HRM> to PAHA with status 'failed' 
ELSE 

choose a random free slot 
store <MRH> while waiting for slot_reached 
ENDIF 
ENDIF 
ELSE 

store <MRH> while waiting for permission to send 
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WHEN <ATD> from DCOD 

IP we have data <MRM> to send THEN 

send copy of <MHM> to CODE for transmission 
ENDIF 

WHEN <ATT> from DCOD 

IF we have speech <MRM> to send THEN 

send copy of <MRM> to CODE for transmission 
ENDIF 



WHEN <NAT> from DCOD 

IF we have speech <MRM> to send THEN 
IF order to leave CURRENT_B AS E THEN 

return. <MHM> to PAHA with status 'failed' 
ELSE 

return <MRM> to PAHA with status 'no channel' 
ENDIF 
ENDIF 

speech_queue := FALSE 

WHEN . .. <ATL>_..f I om. DCOD 

IF we have emergency <MRM> to send THEN 

send copy of <MRM> to CODE for transmission 
ENDIF 

WHEN <SVP> from DCOD 

IF (sub type 1 or 2) and (priority is the same as or 
less than terminal priority) .. THEN 
send <SVP> to PAHA 
ENDIF 

WHEN <TST> from DCOD . 
send signal to Physical Layer that we cannot_send in 
any slot 

WHEN <VKT> from DCOD 
speech_queue := TRUE 
queue timer := timeout value 

send signal SPEECH_QUEOE_INF0 to Application Layer 

WHEN timeout of queue^timer 
speech_queue : = FALSE 

WHEN SILENCE from Physical Layer 

send signal to Physical Layer that we cannot_send in 
any slot 
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IF we have <MRM> to senc 
CASE <MRH> traffic type 
WHEN emergency 

IF <MRM> contains more blocks than MAX_ACCESS 

^"create <ABL> and send to CODE for transmission 
ELSE 

send copy of <MRM> to CODE for transnu.ssi.on 
ENDIF 
WHEN speech 

IF cancel request THEN 

cancel request := FALSE 

create <AAT> and send to CODE for transmission 
ELSE mTTTO 
IF <MRM> with line connection request THEN 
IF <MRM> contains more blocks than MAX_SPEECH 
THEN 

create <ABT> and send to CODE for 
transmission 

ELSE , , 

send copy of <MEM> to CODE for transmission 
ENDIF 
ELSE 

send copy of <MRM> to CODE for transmission 



create <ABD> and send to CODE for transmission 
ELSE 

send copy of <MRM> to CODE for transmission 
ENDIF 
ENDCASE 

increment counter of .attempts to send 
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4.7.4 Coding and readout (CODE ) 

CODE codes the blocks of the frame and transfers the bits 
to the Physical Layer. 



4.7.4.1 Logical description 
LOOP 

Wait for frame to transmit 
Code the blocks of the frame 
Transfer the bits to the Physical Layer 
ENDLOOP 
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4.7.5 Base contact monitoring (BMON ) 

BMON monitors contact with the base station(s) and works 
in 3 different modes: 

-1- Normal Channel Monitoring 

-2- Quick Channel Monitoring 

-3- Disabled 

For further information, see chapter ROAMING. 

Input signals coma from the Physical Layer and from PAHA: 



-1- no_base_contact 
best_BASE 



PAHA 



1 



2 



-2- set_mode_l 
set_mode_2 
set_mode_3- 



-3- received_base 



BMON 



3 



Physical 
Layer 



A 292 SUM 
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4.7.6 Packet handling (PAHA ) 

PAHA handles the conversion between MPAKs and <mrm>- 
frames. It supervises the contact with BASE and informs 
the network when changing BASE and when returning after 
lost contact with the network. 



PAHA is only capable of handling i 
works in three different modes: 



Normal mode 



: MPAK at a time and it 



• Contact with a base station is 
established and the Network Layer may 
send and receive all types of MPAK. 

■ PAHA enters this mode only on order 
from the Network Layer. The Network 
Layer also decides which MPAKs that may 
be sent. PAHA leaves the speech mode on 
order from the Network Layer or when 
the transmission of an <MHM> has 
failed. 

■ When base contact is lost, PAHA enters 
base search mode. MPAKs from the 
Network Layer are not handled in. this 
mode. When a base has been located, 
PAHA returns to normal mode. 

The mobile terminal returns to the relevant system channel 
after the end of all sessions on other channels 
(channel_for_sending_speech, channel_for_sending_data) . 



Speech mode 



Base search mode • 
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Logical description, main program 



IF an old base is saved THEN 
send set_mode_l to BM.ON 
system_channel := current_syscem_channel 
OFRA_scatus := free . 
main_mode := normal_mode 

main_mode := base_search_mode 

ENDIF 



LOOP 

CASE mainjnade 
WHEN normaljraode 

normal 
WHEN speech_mode 

speech 
WHEN base_search_mode 

base_search 
ENDCASE 
ENDLOOP 
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4.7.6.2 Logical description, normal (norraaljnode) 




WHILE main mode = normaljaode 
wait for Input signal 
CASE input signal 




WHEN MPAK TO TRANSMIT from Network Layer 
create <MRM> with new up sequential number 
IP access channel opened THEN 

change to access channel 

channel := channel for_sending_data 
ENDIF 

send <MHM> to OFRA 
OFRA_status := busy 




WHEN MPAK TO RETRANSMIT from Network Layer 
create <MRM> with old up sequential number 
IF access channel opened THEN 

change to access channel 

channel := channel for sending data 
ENDIF 

send <MRM> to OFRA 
OFRA_status := busy 




WHEN SPEECHjON from Network Layer 
raainjnode := speech_mode 




WHEN RETORN_MPAK from Network Layer 
send stop send to OFRA 
wait to get frame that was in progress 
return <MRM> to Network Layer with status 'not 
transmitted' 




WHEN <SVP> from OFRA 
CASE sub type 
WHEN 1 






update parameters 






CASE type of channel 

WHEN local system channel opened 
system channel := local 
change to new system channel 

WHEN local system channel closed 
system channel := previous 
change to new system channel 

WHEN access channel opened 
store access channel 

WHEN access channel closed 
delete access channel 
■ ENDCASE 
ENDCASE 


feproo 
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WHEN <BKT> from IFRA 

IP acknowledgement of <MRM> THEN 

send <ACK> to OFRA 
ELSE 

start timer with timeout value 
ENDIF 

channel := channel_for_speech 
change to designated channel 
send set_mode_3 to BHON 

WHEN <BKD> from IFRA 

IF it is a channel change to send frame THEN 

channel := channel_for sending_data 
ELSE 

channel := channel_for receiving_data 
ENDIF 

start timer with timeout value 
change to -designated channel 
send set_mode_3 to BMON 

WHEN timeout for change of channel 
change to system_channel 
send set_mode_l to BMON 

WHEN <BBT> from IFRA 

store new parameters and change channel 

WHEN <MRtt> With status 'OK* from OFRA 
OFRA status := free 

return MPAK to Network Layer with status 'transmitted' 
priority := normal 

IF channel = channel_for_sending_data THEN 

change to system_channeT 

send set_mode 1 to BHON 
ENDIF 

reset timer for change of channel 

WHEN <MRM> with status 'failed' from OFRA 
OFRA status := free . 

return MPAK to Network Layer with status 'not 

transmitted" 

priority := raised 

mainjnode :=> base_search mode 

reset timer for change oF channel 

WHEN <MRM> with status 'no channel' from OFRA 
OFRA_status := free 

return MPAK to Network Layer with status 'not 

transmitted' 

priority := raised 

reset timer for change of channel 
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WHEN incoming <MRM> from IFRA 
CASE incoming sequential number 
WHEN 0 




check ok := TRUE 
store""riew down sequential number 
WHEN 15 

check ok := TRUE 
WHEN OTHERWISE 

IP different from last seq. number received THEN 
check_ok := TRUE 
stors"new down sscjusntisl number 

^check ok := FALSE 
ENDIF 




ENDCASE 

IF check ok THEN 

IF channel = channel for receiving_data THEN 
IF response NOT required THEN 
change to system_channel 
send set_mode_l to BMON 




ENDIF 
' ENDIF 

send MPAK to Network Layer . 




delete <MRM> 






reset timer for change of channel 




WHEN Frame sent from Physical Layer 
IF frame = <ACK> THEN 

IF channel = channel_f or_receiving_data THEN 
change to system channel 
send set mode 1 to BMON 




ENDIF 

reset timer for change of channel 
ENDIF 




WHEN no base contact from BMON 
IF OFRA status = busy THEN 

send stop send to OFRA 

wait to get frame that was in progress 

return <MRM> to Network Layer with status 'not 

transmitted' 
ENDIF 

main mode := base_search_mode 




ENDCASE input signal 
ENDWHILE 























Exhibit 2, p. 



Cante! Mobitex- 



4.7.6.3 Logical description, base search (base search 
mode) 

wait for input signal BEST_BASE from BMON 
IF roaming value > GOOD_BASE THEN 

CURRENT_3ASE := new base 

CURRENT_SYSTEM_CEANN£L := new channel 

send signal ROAMING to Network Layer 

clear sequential numbers for all groups 

delete access channel 
ELSE 

send signal BASE_LOST to Application Layer 

send order set mode_2 to BMON 

REPEAT 

wait for input signal BEST_BASE' from BMON 
UNTIL roaming value > CHOOSE BASE 
IF base = CORRENT_BASE THEN 

send signal ACTIVATION to Network Layer 
ELSE 

CURRENT_BASE := new base 

C0RRENT_SYSTEM_CHANNEL i= new channel, 
send signal ROAMING to Network Layer 
clear sequential numbers for all groups 
delete access channel 
ENDIF 

send signal BASE_CONTACT to Application Layer 
ENDIF 

send set mode_l to BMON 
mainjnode := normaljnode 



A.29SM5M 
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4.7.6.4 Logical description, speech (speech mode) 




send speech_true to OFRA 






WHILE mainjnode = speech_raode 




CASE input signal 

WHEN speech off from Network Layer 

wait 0.5 seconds 

change to system channel 

send set mode 1 to BMON 

send speech false to OFRA 

mainjuode := norma l_mode 




WHEN new MPAK from Network Layer 

create <MRM> with new up sequential number 
send <MRM> to OFRA 
OFRA_status := busy 




WHEN MPAK from Network Layer to be retransmitted 

create <MRM> with old up sequential number 
send <MRM> to OFRA .. . 
OFRA_status := busy 




WHEN <MRM> with Status 'OK' from OFRA 
OFRA status := free 

IF <MRM> with CSUBCOM:DISCON THEN 
change to sy3tem_channel 
send set mode 1 to BMON 
send speech_false to OFRA 
raain_raode : = normal_raode 




return MPAK to Network Layer with status 'transmitted' 




WHEN <MRM> with status 'failed' from OFRA 

change to system channel 

send set mode 1 to BMON 
• send speech false to. OFRA 

main mode := normal mode 

IP <MRM> with CSOBCOM:DISCON THEN 
send <MRM> to OFRA 

ELSE 

OFRA_status := free 

return MPAK to Network Layer with status 'not 
transmitted' 
ENDIF 




WHEN <BBT> from IFRA 

store new parameters and change channel 
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WHEN incoming <HRM> from IPRA 
CASE, incoming sequential number 
WHEN 0 

send MPAK to Network Layer 
store new down sequential number 
WHEN 15 

send MPAK to Network Layer 



IF different from last seq. number received 
send MPAK to Network Layer 
store new down sequential number 

ELSE 

delete <MRM> 

ENDIF 
ENDCASE 

WHEN signal from BMON 
ignore this signal 
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TRANSFER EXAMPLES 



This chapter describes the most 
the protocol. 



transfer cases of 



4.8.1 Transfer without response 

Transfer without response can only take place in the 
direction BASE to MOB. 

In traffic to mobile terminal! s) BASE often addresses more 
than one MOB. This can apply to traffic to group numbers 
or frames where masked addressing occurs. In these cases 
MOB will not transmit a response. BASE states this by not 
setting the response flag in these frames. 



Ex 1;1 



Transfer without response, <MRM> BASE — > MOB 




-> t 
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Transfer with simple acknowledgement 



BASE has full control over the down frequency and can 
transmit an <MRM>-frame at any time to a certain MOB. If 
the response flag is set and no incorrigible bit error has 
been detected in the frame, MOB should reply with <ACK>. 



Transfer with response, <MRM> BASE — > MOB 

BASE <MRM> 

MOB <ACK> 

> t 



Note that <ACK> is sent without considering slot 
boundaries and other access limitations. 



Transfer with response, <MRM> 


MOB - 


•--> BAS 


E 


BASE <FRI> <ACK> 
MOB <MRM> 











By transmitting <FRI>, BASE allows MOB to transmit <MRM>. 

In this case MOB expects an acknowledgement from BASE. The 
lack of an acknowledgement is indicated in this case by 
MOB receiving a <FRI> without having previously received 
acknowledgement of its frame. Frame repetition follows in 
this case. 

Free slots is defined, and thus access permission to the 
up channel is granted, when BASE transmits a <FRI> with an 
address that is applicable to MOB. Access permission is 
withdrawn for a certain MOB if any of the following cases 
arise. 

1 BASE transmits a silence signal (see reference 
Rl-17). This signal applies to all terminals. 

i address which applies 

The free-cycle period as defined in the <FRI>-signal 
expires. 



A 212315&3 
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4.8.3 Transfer with block repetition 

If the receiver of -an <MRM> detects that one or more of 
the following blocks is incorrigible, the receiver may 
request repetition of these blocks with a <REB>. The 
sender replies with a <RES>. 

NOTE Block repetition occurs only on <MRM>-f rames where 
the number of blocks is 3 or more. 



Transfer with block repeat, MOB > BASE 

BASE <REB> <ACK> 

MOB <MRM> <RES> 

> t 



The principle described in the figure above applies in the 
direction to BASE and in the direction to MOB. 
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4.8.4 Transfer with frame repetition 




Frame repetition can occur for three reasons: 




1 The receiving unit transmits a <NAK> 




2 The receiving unit does not transmit a response 




3 The packet type results in frame repetition 




EX 4.1 








Transfer with negative 


acknowledgement MOB > BASE 








BASE < MRM > 

MOB <NAK> 


<MRM> 

<ACK> 

> t 






If the receiving unit finds that the received frame is 
incorrectable and is less than 3 blocks, it can notify the 
sender unit by transmitting a <NAK>. The transmitting unit 
should then repeat the message. The principle above 
applies in both transmission directions. 




The frame is- repeated immediately after an <NAK> is 
received, regardless of slot boundaries. 




1 


:x 4.2 








Transfer with frame repeat, MOB > BASE 








BASE <EHI> <ACK> <FRI> <ACK> 
HOB <MRM> <KSH> 

xxxxx > t 






In this example the first acknowledgement from BASE is 
destroyed by interference so that MOB retransmits the same 
message after the next free signal. 











A2S2SU3.3 
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Ex 4.3 



Transfer with frame repeat. 



BASE > MOB 



BASE 
MOB 



< MRM > 



<MRM> 



t 



In this example, frame repeat is caused by the packet type 
demanding repeated transmission. The response flag is 
never set in this case. 

This case occurs for MPAK to group numbers. To avoid 
repeated presentation of the information in the frame, the 
frame has got a sequential number. According to the 
principles for sequential numbering, MOB will ignore 
subsequent identical frames. 

NOTEl At the restart of a base radio station, the 



sequential numbers for all groups are set to 0. This 
is done to ensure that mobiles will not loose the 
first message to a group. The consequence of this 
action will be that the first" message may be 
presented MAX REP + 1 times at the- mobile terminal. 
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4.8.5 Transfer with access request 



If an <MRM>-frame to be sent from MOB to BASE is longer 
than MAX_ACCESS this <MRM> may not be sent during free 
slots. These longer frames are handled with access 
request, <ABD>, and access permission, <ATD>. 



Transfer with access request, MOB" > BASE 

BASE <FRI> <ATD> <ACK> 

MOB <ABD> ' <MHM> 



The principle is that instead of MOB transmitting its 
<MRM>-frame, it transmits an <ABD>-frame. The reply to. 
this request is an access permission, <ATD>. When MOB 
receives access permission, it immediately starts 
transmitting the <MRM>. 



Repetition with maxjrep, MOB — > BASE 

BASE <FRI> ,.<FRI> . ...<FRI> 

MOB <ABD> <ABD> ' 



When the number of transmitted access requests is 
equal to MAX REP+1 and another <FRI> is received, the 
MPAK is returned to the network layer and a new base 
is chosen. 



Exhibit 2, p. 



Cantel Mobitex- 



9/1056 - A 296 5171/02 Ue 



1990-02-26 A 



Transfer with line connection 



The line connection session is described in reference 
Rl-09. When HOB wants to send an <MRM> (containing a 
request for a line connection) longer than MAX_SPE£CH it 
must request access for this. The access request results 
in a channel change order. On the new channel the session 
for frames takes place to establish the line connection. 
When the line connection is concluded MOB returns to the 
system channel. 



EX 6.1 



Transfer with line connection 






BASE cl <FHI> <BKT> 








BASE c2 


<ATT> <ACK> 






MOB Cl <ABT> 








MOB C2 


<MRM> 






tl t2 t3 













tl: Disable roaming and start timeout with time from 

<BKT>. 
t2: Stop timeout. 

t3: Speechjon received from Network liayer. 
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4.S.7 Transfer on several channels 

Transfer on several, channels can be divided into two 
separate cases: 

1 MOB apoears on another channel because BASE has 
stated* in a <SVP>-frame that all traffic from a 
mobile terminal shall be sent on a channel other 
than that on which the <SVP> came. 

2 BASE transmits a <BKD>-frame as .a reply to an <ABD>. 



EX 7.1 



Transfer on several channels 

BASE cl <FRI> <BKD> 
BASE c2 <ATD> 
MOB cl <ABD> 
MOB C2. <M 
tl 


<ACK> 

RM> 

t2 







tl: Disable roaming and start timeout with time from • 
<BKD> . 

t2: Return to system_channel, enable roaming. 



In this example, the access request from MOB resulted in a 
channel change order. The access permission is transmitted 
on channel c2. After having received an acknowledgement, 
MOB returns to channel cl. 
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4.8.8 Line connection 


with hand over 





Ordinary line connection 

BASEl,cl <FRI> <BKT> 
BASEl,c2 <ATT> 
MOB, cl <ABT> 
MOB, c2 



speech 
speech 



tli Ordinary connection established. 



EX 8.2 



Continued with <BBT> 




BASE2,cl 










BASE2,c3 




. . speech . 


<ACK> 




BASEl,cl 








BASEl,c2 


<BBT> 








MOB, cl 










MOB, c2 










MOB, c3 




.. speech . 


DISCON 




t2 t3 t4 


t5 










>t 



t2: Hand over to base 82. 

t3: MOB connected to base B2 on new speech channel, new 

system channel stored for later use. 
t4: MOB breaks connection and changes to the new system 

channel. 
t5: Connection ended. 
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4.8.9 Line connection with queue handling . 



If no speech channel is immediately available, BASE 
may place MOB in a queue of callers and reply with 
<VKT>. 



Succesfully established line connection 
BASE1,C1 <FRI> <VKT> ... <BKT> 

BASEl,c2 <ATT> <ACK> speech 

MOB, cl <ABT> 

MOB, c2 CONREQ . speech 



tl-t2: Waiting time. 

t3: Connection established. 



Call attempt ended by BASE 

BASE1 , cl <PRI> <VKT> J ... I <NAT> I 
MOB, cl <ABT> I... I I 

tl t2 t3 



tl-t2: Waiting time. 

t3: Call attempt ended. 



Call attempt ended by MOB 

BASE1 , cl <FRI> <VKT> I ... I I 
MOB, cl <ABT> I ... I <AAT> I 

tl t2 t3 



tl-t2: Waiting time. 

t3: Call attempt ended. 
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Call attempt ended by MOB 

BASE1 , Cl <FRI> <VKT> I ... I <VKT> I 
MOB, Cl <ABT> I... I I 



tl-t2: Waiting time. 
t3-t4: Waiting time. 
tS: Call attempt ended. 
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4.8.10 Line connection without access request 



When MOB wants to send an <MRM> (containing a 
request for a line connection) shorter than or equal 
to MAX_SPEECH no access request is needed. 

The response to the <HHM> is a channel change order 
that includes an acknowledgement. The line 
connection is immediately established on the new 
channel. 



EX 10.1 



Line connection without access request 

BASE Cl <FR1> <BKT> 

BASE c2 . . speech . . 

MOB cl <MRM> 

MOB c2 .. speech .. 

> t 



4.8.11 Ending a line connection 

An <MRM> with a DISCON may be transmitted only once 
on the speech channel. If MOB have not received 
<ACK> within 2 seconds, it changes to the system 
channel and continues the transmission attempts 
according to the usual rules. 



Ending a line connection 
BASE cl 

BASE c2 . .speech. . . 
MOB cl 

MOB c2 ..speech., DISCON 



<FRI> <ACK> 
DISCON 
tl t2 t: 



tl-t2: Timeout. 

t2: ■ Return to system_channel, enable roaming. 
t3: Connection ended. 
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4.8.12 Line connection ended by speech off 



After the mobile terminal has received an <MRM> 
containing a line connection request, the session 
may be put to an end by the signal speech_off from 
the network layer. This signal is generated by a 
timeout (please see reference Rl-09) when che 
operatdr has not answered the call. 



Connection ended by signal speech_off 



BASE cl <BKT> 
BASE c2 
MOB cl 



tl: Disable roaming and start timeout with time from 

<BKT>. 
t2: Stop timeout. 

t3: Speech_off received from Network Layer. Return to 
system channel and enable roaming: 
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5 SYSTEM PARAMETERS TO BE STORED IN THE TERMINAL 

Certain svstem parameters are stored continuously (even if 
the terminal is powered off) in MOB to permit correct 
action whan starting up. These are: 

The terminal subscription MAN 

Grouo number list (GROOPLIST) 
Maximum number of retransmissions allowed (MAX_R£P) 
Sequential numbers - terminal MAN (up/down) 
Current base 
Current system channel 

A list of the area identifications that the mobile 
is allowed to use. Please see reference Rl-06. 

When switched on, all these parameters apply until a frame 
is received containing the current parameter values. 

There is also a permanent (and possibly a temporary) 
default list of system channels used by the roaming 
algorithm. They are stored continuously and have the 
following general format: 



channel 


#1 




channel 


#n 



total number of channels (2 bytes) 
system channels 



A channel is defined as a pair of frequencies and all the 
channels of this list are given in reference Rl-06. 
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6 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 17, 22, 31, 62 
Rl-09, 4, 7, 55, 61 
Rl-17, 5, 14, 17, 24, 50 



Below are the reference designations listed. 



Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

R1-Q3 General description of terminals ....... . . 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 • Application layer 

Rl-09 Network layer- 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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ABSTRACT 

This document describes frame structure and coding for the 
Data Link Layer. 
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1 INTRODUCTION 



1.1 GENERAL 



The mobile terminal's Data Link Layer together with the 
Physical Layer form a radio protocol for communication 
between mobile stations (HOB) and a base radio station 
(BASE). 

The interchange of information between BASE and MOB is in 
the form of frames. There are 21 different types of 
frames. 
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2 FRAME TYPES 



There are 21 different frame types: 

Name Designation Transmitted by 
BASE MOB 



1 


M frame 


<MRM> 


Yes 


Yes 


2 


Acknowledgement 


<ACK> 


Yes 


Yes 


3 


Negative acknowledgement 


<NAK> 


Yes 


Yes 


4 


Repetition request 


<REB> 


Yes 


Yes 


5 


Repetition reply 


<RES> 


Yes 


Yes 


6 


Access request, data 


<ABD> 


No 


Yes 


7 


Access request, speech 


<ABT> 


No 


Yes 


a 


Access request, emergency 
Access permission, data 


<ABL> 


No 


Yes 


9 


<ATD> 


Yes 


No 


10 


Access permission speech 
Access permission, emergency 


<ATT> 


Yes 


No 


11 


<ATL> 


Yes 


No 


12 


Change channel, data 


<BKD> 


Yes 


No 


13 


Change channel, speech 


<BKT> 


Yes 


NO 


14 


Free signal 


<FRI> 


Yes 


... No 


15 


Sweep signal 


<SVP> 


Yes 


No 


16 


Silence order 


<TST> 


Yes 


NO 


17 


Activity request 


<AKT> 


Yes 


No 


18 


No access permission, speech 


<NAT> 


Yes 


NO 


19 


Change base station, speech 


<BBT> 


Yes 


No 


20 


Wait for channel, speech 


<VKT> 


Yes 


No 


21 


Cancel access request, speech <AAT> 


No 


Yes 
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3 DESCRIPTION OF GENERAL FIELDS 

In this chapter the general fields of a frame are 
described. Fields occuring only in specific frame types 
are described in conjunction with the definition of the 
respective frame type. 

The fields are described in the following order: 

address of mobile terminal, or group 
type of frame 

number of blocks in the frame 
check sum 

for masked addressing 
for priority addressing 
frequency number, up frequency 
frequency number, down frequency 
number of retransmissions 



1 


MOB 


2 


TYPE 


3 


BLOCK 


4 


PARITY 


5 


MASK 


6 


PRIO 


7a 


UPFREQ 


7b 


DOFREQ 



The most significant bit lies .to the left in the field, 
has the lowest order number and is sent and received first 
in time. 



01 02 03 04 05 



MOB states the address of the mobile unit concerned. 
This address refers to the terminals own 
subscription number, or to any number representing a 
group to which the terminal belongs. 
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TYPE is bit 28-32 of the primary block and indicates 
the type of frame according to the following table: 



Value 
Decimal Binary 



Type 

designation 



01 


00001 


<MRM> 


02 


00010 


<ACK> 


03 


00011 


<NAK> 


04 


00100 


<REB> 


05 


00101 


<RES> 


06 


00110 


<ABD> 


07 


. 00111 


<ABT> 


OS 


01000 


<ABL> 


09 


01001 


<ATD> 


-10 


010*0- - 


<ATT> 


11 


01011 


<ATL> 


12 ' 


. 01100 


<BKD> 


13 


01101 


<BKT> 


14 


OHIO 


<FRI> 


15 


onii 


<SVP> 


16 


10000 


<TST> 


17 


10001 


<AKT> 


18 


10010 


<NAT> 


19 


10011 


<BBT> 


20 


10100 


<VKT> 


21 


10101 


<AAT> 



States the number of blocks in the frame, including 
primary block. 



PARITY 01 02 03 . . 14 15 16 



A frame comprises one or more blocks. A block 
•comprises a source word and a coded parity word. 
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MASK 01 02 03 04 05 



A group of terminals is addressed with masked 
addressing. The MASK states the number of most 
significant bits of the MOB address that should be 
ignored. 



PRIO 01 02 03 



PRIO 


7 


111 


6 


110 


5 


101 


4 


100 


3 


011 


2 


010 


1 


001 


0 


000 



Meaning 



Priority group 4, raised priority 

, normal 

Priority group 3, raised priority 

" , normal 

Priority group 2, raised priority 

" r normal 

Priority group 1, raised priority 

. " f normal 



OPFREQ 01 02 03 04 



12 13 14 15 -16 



I <-FHI — > I < FREQ. NO. > 

DOFREQ 01 02 03 . . . 12 13 14 15 16 
1 I 1 1 1 ' ' 



States the frequency number, OPFREQ for transmit 
frequency and DOFREQ for receive frequency. 

Bit 1 to 3 gives FBI (frequency band and bit rate 
INFORMATION) and bit 4 to 16 gives the frequency 
number. Both the parameters are defined in reference 
Rl-06. 



NUMRET 01 02 03 04 05 06 07 > 



States the number of retransmissions, including the 
current try. 
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4 FRAME TYPE DESCRIPTIONS 


4.1 FRAME TYPE <MRM>, M 


-frame 



APPLICATION An <MRM> is used to transfer packets. The 
packet format is defined in reference 
Rl-09 . 



PRIMARY BLOCK 

01 02 03 



0 0 0 0 1 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 



— 1 I I ' ■ 



States the number of valid octets in the 
last following block. Remaining octets of 
the last block are filled with "0" to give 
a complete block. The field contains 6 
bits and is used in the following way: 

26 27 33 34 35 36 



SEQUENCE States the sequential number of the frame. 

RE States whether a response is to be given 

to the frame. The mobile terminal shall 
always set this flag to "1" on 
transmission. 

INFO Contains 12 octets of source data from the 

packet . 
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FOLLOWING BLOCK 








APPLICATION The packet is placed in the following 

blocks with 18 octets from the packet in 
each. The number of valid octets in the 
last following block is indicated in the 
OCTET field of the primary block. The last 
following block is filled with "0" in the 
octets which do not belong to the packet. 






01 02 03 04 05 06 


144 

i i i i i i 








INFO 








145 

i i i i i i 


160 

i i i i i i i i i 








PARITY 




- 


INFO Contains 
packet. 


18 octets of source data from 


the 
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4.2 FRAME TYPE <ACK>, Acknowledgement 


APPLICATION An <ACK> acknowledges a correctly received 


frame. 





<ACK> indicates that all blocks In the 
frame have been correctly received. It 
includes the sequential number of the 
received frame. 



PRIMARY BLOCK 



01 02 03 22 23 24 25 26 27 28 29 30 31 32 
I I 1 I 1 I I I I 1 1 1 1 1 



L .. .1, ..1 -1 — 1 1 1 

MOB 


1 1 

0 0 0 


0 0 


0 


— 1 — 

1 0 


33 34 


35 


36 


37 38 39 40 


41 42 43 

i i 


44 45 


46 


47 48 
i 


0 "0 


0 


0 


SEQUENCE 


BLOCK 


49 SO 
L 


51 

I 1 


52 


53 .54 




1 1 


..... 


. 144 


0 0 


0 


0 


0 0 


0 


0 0 


0 


0 0 


145 


1 1 






I 1 1 




1 


160 

! 



PARITY 



States the sequential number of 
the corresponding <MRM>-f rame. 



No following blocks in this type 
of frame. 
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4.3 FRAME TYPE <NAK>, Negative acknowledgement 

APPLICATION A <NAK> requests repetition of the entire 
<MRM>. 

<NAK> indicates that the primary block has 
been correctly received, but that the 
following blocks have been lost. It 
contains the sequential number of the 
received primary block. <NAK> results in a 
complete repetition of the lost <MRM>. 

Note that if the number of blocks in <MRM> 
was 3 or more, <REB> is used instead of 
<NAK>. 



PRIMARY BLOCK • 
01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



, 1 I ... ,.J .. _.L 1 1 

MOB 


0 0 0 


0 0 


0 


1 1 


33 34 


35 


36 


37 38 39 40 


41 42 43 

i • i 


44 45 

i 


46 


47 48 

i 


0 0 


0 


.0 


SEQUENCE 


BLOCK 


49 50 


51 
1 


52 


53 54 


i 






144 

I 


(__L _J 
0 0 


0 


- 

0 


0 0 


0 


0 0 


. 

0 


0 0 


145 

,„ l ... 


_J 




_ 1 — 1 1 


1 .. ,.l ., 


1 




160 



States the sequential number of 
the corresponding <MRM>-frame. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.4 FRAME TYPE <REB>, Repetition request 
APPLICATION 



A <REB> requests repetition of erronous 
blacks in an <MRM>. 

If it is found during reception that 
certain blocks in a frame cannot be 
corrected ; a request for these blocks to 
be repeated can be made by transmitting a 
<REB>. The request contains a bit map of 
the blocks to be repeated. This bit map 
refers to the original <MRM>, even during 
a sequence of repetitions. 

<REB> contains the sequential number of 
the received <MRM> primary block and 
results in a <RES>. 

Note that if the number of blocks in <MRM> 
was 2 or less, <NAK> is used instead of . 
<REB>. - 



PRIMARY BLOCK 



01 02 03 22 23 24 
1 i .!_ — I 1 1 1 


25 26 27 
i i 


28 29 30 31 32 
1 1 i 1 


MOB 


0 0 0 


0 0 1 0 0 


33 34 35 36 

iii. 


37 38 39 40 


41 42 43 44 45 46 47 48 

I 1 1.1 1 J _! 1 


0 0 0 0 


SEQUENCE 


BLOCK 



I.I — I — I — 
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the corresponding <MRM>-f rame. 

REPMAP Contains a bit map where each 

bit represents a block in the 
<MRM> previously received. A bit 
set to "1" indicates chat the 
corresponding block is to be 
repeated. The bit in a REPMAP 
representing the primary block 
shall always have the value "0", 
since repetition of the primary 
block is illegal-. 



FOLLOWING BLOCK No following blocks in this type 

of frame. 
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4.5 FRAME TYPE <RES>, Repetition reply 

APPLICATION A <RES> is the reply to a <REB>. 

<RES> is a selective repetition of blocks 
from an <MRM>. The following blocks of the 
<RES> contain copies of blocks according 
to the bit map of the <REB>. <RES> 
contains the sequential number of the 
original <MRM>. 



PRIMARY BLOCK 



01 02 03 22 23 24 25 26 27 28 29 30 31 32 
I 1 1 1 1 1 1 1 1 1 1 1 1 1 



1 — 1 — 1 — 1_ _1 — 1 — 1 — 1 

MOB 


1 1 

0 0 0 


0 0 10 1 


33 34 35 36 37 38 39 40 
1 1 1 1 1 1 1 


41 42 43 44 45 46 47 48 

i i i i i ,- i i 


0 0 0 0 SEQUENCE 


BLOCK 



49 50 51 52 53 54 , 144 

I l l 1 1 1 1 1 1 1 1 1 

0 0 0 0 0 0 0 0 o o o o 



SEQUENCE States the sequential number of the 
corresponding <MRM>-frame. 



A.JMSISW 
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FOLLOWING BLOCK 
APPLICATION 



The following blocks contain copies of 
blocks according to the bit map of the 
<REB>. Only blocks requested to be 
repeated shall be packed into the 
following blocks. The order of the blocks 
is that stated in REPMAP. 



01 02 03 04 05 06 



144 



REPBLOCK The copy of a block from the original 
<MRM>-£rame. 
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4.6 FRAME TYPE <ABD>, Access request, data. 

APPLICATION An <ABD> is a request to transmit an <MRM> 
whose length (number of blocks) exceeds 
the value of MAX_ACCESS. 

If the length of the <HRH> exceeds 
MAX_ACCESS, access must be requested 
before the <MRM> may be sent. 

The <ABD> states the number of blocks in 
the corresponding <MRM>. 



PRIMARY BLOCK 



22 23 24 25 26 27 28 29 30 31 32 



49 50 51 52 53 54 55 56 57 



-1 1 1 1 I L_ 



States the number of blocks for 
..which access is requested. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.7 FRAME TYPE <ABT>, Access request, speech 

APPLICATION An <ABT> is a request to transmit an <MRM> 
containing a request for a line 
connection, whose length (number of 
blocks) exceeds the value o£ MAX_SPEECH. 

The <ABT> states the number of blocks in 
the corresponding <MRM>. 



PRIMARY BLOCK 



22 23 24 25 26 27 28 29 30 31 32 



0 0 111 



49 50 51 52 53 54 55 56 57 



States the number oE blocks for 
which access is requested. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.8 ERAME TYPE <ABL>, Access tequest, emergency. 

APPLICATION An <ABL> is a request to transmit an <MRM> 
containing an emergency signal whose 
length exceeds the value of MAX_ACCESS. 

If the length of the <MRM> exceeds 
MAX_ACCESS/ access must be requested 
before the <MRM> may be sent. 

The <ABL> states the number of blocks in 
the corresponding <MRM>. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



1 — I — 1 — 1_ — 1 — J — 1 — 

MOB 


0 


0 0 


! 

0 1 


I 

0 


., 1 
0 0 


33 34 35 36 37 38 


39 40 

i 


41 


42 4.3 


44 45 


46 


47 48 


BLOCK N 


BLOCK 


49 50 51 52 53 54 
ii i i i 


55 56 

i 


57 




_J 


, 


144 

1., ., 


NUMRET 


0 






0 


0 0 


145 

i i i i i 




1 1 




I 


_i 


160 



States the number of blocks for 
which access is requested. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.9 FRAME TYPE <ATD> , Access permission, data. 




APPLICATION BASE replies with an <ATD> to an <ABD> 

from a MOB, when BASE is ready to accept 
an <MRM>. 




When permission is granted, MOB is 
expected to transmit an <MRM> containing a 
data packet. 


PRIMARY BLOCK 












01 02 03 22 


23 24 


25 26 27 


28 29 30 31 32 






MOB 


0 0 0 


0 10 0 1 






33 34 35 36 37 38 

1 1 1 | I L 


39 40 


41 42 43 


44 45 46 47 48 






0 0 0 0 0 0 


0 0 


BLOCK 






49 50 51 52 53 54 
■ ' ' 1 1 1 






144 

l_J 1 1 1 






0 0 0 0 0 0 




0 


0 0 0 0 0 






145 

i i i i i i 






160 






PARITY 





No following blocks in this type 
of frame. 
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4.10 FRAME TYPE <ATT>, Access permission, speech. 

APPLICATION BASE replies with an <ATT> to an <ABT> 

from a HOB, when BASE is ready to accept 
an <MRM>. 

When permission is granted, MOB is 
expected to transmit an <MRM> containing a 
request for line connection. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



1 1 L— _U 1... 1, 

MOB 


1 I 

0 0 0 


0 1 


1 1 

0 10 


33 34 


3S 36 37 
' » 


38 39 40 


41 42 43 


44 45 
i 


46 47 48 

i r 


0 0 


0 " o "~o 


0 0 0 


BLOCK 


49 50 
1— J 


51 52 53 
i • 


54 






. 144 


0 0 


0 0 0 


0 


0 


0 0 


1 

0 0 0 


145 

i 


1 1 


1 1 







160 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 



Exhibit 2, p. 



Cantel Mobitex- 



91/1056 - A 296 5171/A2 Oe 



1990-02-22 A 



4.11 FRAME TYPE <ATL> , Access permission, emergency. 

APPLICATION BASE replies with an <ATL> to an <ABL> 

from a MOB, when BASE is ready to accept 
an <MRM>. 

When permission is granted, HOB is 
expected to transmit an <MRM> containing 
an emergency signal. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



0 10 1 1 



33 34 35 36 37 38 39 40 41 42 43 



45 46 47 48 



0 0 0 0 0 0 0 



49 50 51 52 53 54 
I ' ' ' I L 

0 0 0 0 0 0 



. 1 1 1 L_ 



0 0 0 0 0 0 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.12 FRAME TYPE <BKD>, Change channel, data- 
APPLICATION 



A <BKD> orders a MOB to another channel in 
order to transmit or receive an <MRM>. 

The MOB usually returns to the original 
channel when the <MRM> has been 
transmitted or received. If an error 
occurs on the assigned channel then MOB 
returns to the original channel after a 
timeout period stated in the <BKD>. 



PRIMARY BLOCK 



01 02 03 


22 


23 


24 


25 


26 


27 


28 29 


30 


31 


32 


MOB 


0 


0 


0 


0 1 


1 


0 


0 


33." 34 35 36 37 
_l ..1... 1 1 .. 


38 


39 


40 


41 


42 


43 


44 45 


46 


47 


48 


0 0 0 □ 0 


0 


0 


0 


BLOCK 



49 64 65 

BKDFL 



97 

f TIMEOUT 



OPFREQ 



)FRE Q ' | 



DOFREQ 



0 0 0 0 0 
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Indicates how the terminal is to act on 
the new channel. 

1 . Reserved 

2 Reserved 

3 Reserved 

4 Change to send <MRM> 

5 Change to receive <MRM> 
6.. 16 Reserved 



Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

Frequency number of down frequency, i.e 
the frequency on which BASE transmits. 

If error, return after TIMEOUT seconds 
(1-255). 



FOLLOWING .BLOCK 



No following blocks in this type 
of frame. 
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4.13 FRAME TYPE <BKT>, Change channel, speech. 

APPLICATION A <BKT> orders a MOB to another channel in 
order to transmit or receive an <MRM> 
containing a request for line connection. 

Normally the terminal returns to the 
original channel when the line connection 
is over. If an error occurs on the 
assigned channel then. MOB returns to the 
original channel after a timeout period 
stated in the <BKT>. . 



PRIMARY BLOCK 

01 02 03 22 23 24 25 25 27 28 29 30 31 32 



L l.,__L^_l 1 1 1 

MOB 


0 0 0 


0 110 1 


33 34 35 36 
1 ! ._! 


37 38 39 40 


41 42 43 44 45 46 47 48 


0 0 0 0 


SEQUENCE 


1 ' • ' ' ' ' ' ' 1 
BLOCK 



49 64 65 

BKTFL 



| BKTFI 
97 

| TIMEOI 



0.0 0 0 0 



145 160 
I 1 I I I 1 1 1 1 L 1 1 1 1 " 1 1 
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SEQUENCE Only valid if BKTFL bit 6 is TRUE. 



• Indicates how the terminal is to act on 
the new channel. 

Bit 1 - Reserved 

2 Reserved 

3 Reserved 

4 Change to send <MRM> 

5 Change to receive <MRM> 

6 Acknowledgement, (including sequence 
number) of correctly received speech 
<MRM>. Ignore timeout. 

7 . . 16 Reserved 



UPPREQ ■ Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

DOPREQ Frequency number of down frequency, i.e. 

the frequency on which BASE transmits. 

TIMEOUT If error, return after TIMEOUT seconds 
d-255). 



FOLLOWING BLOCK 
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4.14 FRAME TYPE <FRI>, Free signal 
APPLICATION 



BASE transmits a <FRl> when it is ready to 
handle traffic from MOB. 

A free signal precedes a free cycle. A 
free cycle is a period of time when all 
of., or parts of, the total fleet of mobile 
terminals are collectively permitted to 
transmit. 



PRIMARY BLOCK . 



22 23 24 25 26 27 28 29 30 31 32 



0 1110 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 



49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 



RAND SLOTS 



65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 



MAX ACCESS 



SLOT LENGTH 



81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 



MAX SPEECH 



00000000 



0 0 0 0 0 0 



I I I ! 1 1 — 
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FFG The FFG field states the type of traffic 

to which the free signal applies according 
to the following table. 


Value Emergency Sneech Data 


00 
01 
10 
11 


yes no no 
yes no yes 
yes yes no 
yes yes yes 


RAND_SLOTS 


The maximum, number of the random 
number generator which selects 
in which slot. the transmission 
shall start. 


FREE_SLOTS 


The number of free slots in this 
free cycle. 


MAX_ACCESS 


States the number of blocks 
which may be sent in an <MHM> 
without being preceeded by an 
access request. 


SLOT_LENGTH . 


Current value of slot_length. 


MAX_SFEECH 


States the -number of blocks 
which- may be sent in a line 
connection request without being 
preceeded by an access request. 


FOLLOWING BLOCK 


No following blocks in this type 
of frame. 
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4.15 FRAME TYPE <SVP>, Sweep signal 

APPLICATION The sweep signal is a periodically 

recurring signal from BASE. An <SVP> is 
transmitted by BASE for two reasons: 

1 <SVP> marks the start of a swe< 
cycle. 

2 <SVP> contains system 
parameters. 

<SVP> has 2 different subtypes: 

1 states the values of system 

parameters 

• 2 states the frequency of 

different channel types 
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<SVP>, SUBTYPE 1 



- states the values of system 
parameters. 



PRIMARY BLOCK 

. 01 02 03 22 23 24 25 26 27 28 29 30 31 32 



0 1111 



33 34 35 36 37 38 39 40 


41 42 43 44 45 46 47 48 


1 1 j 1 1 1 1 

PRIO MASK 


BLOCK 


49 50 51 52 53 54 55 56 


57 58 59 60 61 62 63 64 

I I 1 1.1 1 . _! 1 


SVPTYP 


TXPOW 


65 66 67 68 69 70 71 72 
1 1 1 1 1 1 1 


73 74 75 76 77 78 79 80 
I i 1 1 1 ! 1 1 


RSSI PROC 


RSSI PERIOD 


81 82 83 84 85 86 87 88 
__i 1 1 1 1 1 1 


89 90 91 92 93 94 95 96 
I, 1 1 1 1 1 1 1 


TIME TO NEXT 


" MAX REP 


97 104 
1 1 1 1 1 1 1 


105 112 

' ' ' • ' i i- J— —J 


BASEST 


SCAN_TIME 


113 120 


121 128 
i i i i i i i 


BAD BASE 


GOOD_BASE 


129 136 
1 I I I 1 1 1 


137 144 
■ i i i i i i 


BETTER BASE 


00000000 


145 160 
1 1 1 1 1 1 1 1 1 1 1 1 1 " 1 


PARITY 
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SVPTYP 


States the <SVP> subtype, value 
00000001 in this case. 


TXPOW 


States the decrease in output 
power (0—255 dB below nominal 
level) to be used by the mobile. 
A default value of 0 is used 
until this signal is received. 


RSSI_PROC 


States, the method of the signal . 
strength measurement: 

0 = FRAME 

1 = CONTINUOUS 

The default value is FRAME. 


RSSI_PERIOD 


Time used by the roaming 
algorithm (0-255 *20 ms) . 
Default value: 148 (2 960 ras). 


TIHE_TO_liEXT_. 


States the time in seconds to 
the next <SV?> frame. 
Default value: 10. 


MAX REP 
BASEST 


States the value of the variable 
Max_rep. 

States status of base station. 


SCAN_TIME 


States the length of a period 
(0-255 *100 ms) when the 
terminal scans other system 
channels . 

Default value. 30 (3 seconds) • 


BAD_BASE 


Used by the roaming algorithm. 
0-255 dBuV. Default value: 15. 


GCX)D_BASE 


Used by the roaming algorithm. 
0-255 .dBuV. Default value: 15. 


BETTEH_BASE 


Used by the roaming algorithm. 
0-255 dB. Default value: 10. 


Most of the parameters above are further described in the 
MAIN DOCUMENT. 
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FOLLOWING BLOCKS 



FOLLOWING BLOCK #1 



If any, they contain a list of 
system channels to be used in 
base station monitoring. A frame 
with a list containing new 
system channels completely 
overrides the previous frame. 
The channel list has the 
following format (as described 
in the MAIN DOCUMENT) : 



01 02 03 04 05 06 07 08 
III I.-.J -J 


09 10 11 12 13 

1 1—1 L_ _.!„.,_ 


14 15 16 
1 1 


number of channels 


0 0 0 0 0 


0 0 0 


17 32 


33 


48 

1 1 


channel #1 - UPFREQ 


channel #1 - 


DOFREQ 


49 64 


65 


80 

I I 


| 1 .... I 1— .- 

. channel #2 - UPFREQ 


channel #2 - 


DOFREQ 


81 96 
,,11 1, 1 


97 


.112 
_l_ .1 — J 


channel #3 - UPFREQ 


channel S3 - 


DOFREQ 


113 128 


129 


144 
.... _J... _l 


channel #4 - OPFREQ 


channel #4 — 


DOFREQ 


145 

l I l I l l l 


1.1 1 1 


160 



The number of following blocks depends on the size of the 
list. The maximum number of channels in the list is stated 
in reference Rl-06. 

Continues with following block #2 on the next page. 
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FOLLOWING BLOCK #2 
01 



— I 1 - 



— 1 — 1 — 

DPFREQ 


channel #5 - 


I I 
DOFREQ 


48 

1 i 


49 


64 

1 1 


DPFREQ 


channel #6 - 


DOFREQ 


144 

1 1 


145 


160 


UPFREQ 


PARITY . 



- FOLLOWING BLOCK #3 



channel #9 - DOFREQ 



channel #10 - DPFREQ 



33 48 
1 1 L . 1 1 ! 


49 64 


channel #10 - DOFREQ 


channel #11 - DPFREQ 
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<SVP>, SUBTYPE 2 
PRIMARY BLOCK 



• states the frequency of 
. different channel types. 



0 1111 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 - 



1 1 

PRIO 


i 1 1 i 

MASK 


BLOCK 


49 50 51 


52 53 54 55 56 


57 


58 59 60 61 


62 


63 64 
i 


SVPTYP 


CHATYP 


65-66 67 
i i 


68 69 70 71 72 


73 


74 75 76 77 


78 


79-80 


OPFREQ 


81 82 83 

i i 


84 85 86 87 88 
iiii 


89 


90 91 92 93 

i i i 


94 


95 96 


DOFHEQ 


97 98 99 
1 1 1 1 


100 




. i .1 . J_ .. 




144 


0 0 0 


0 0 0 




0 0 0 


0 


0 0 
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States the <SVP> subtype, value 00000010 
in this case. 

States the type of channel: 
Value: 

1 Local system channel opened 

2 Not used (ignore that order) 

3 Local system channel closed 
(return to national system 
channel ) 

4 Access channel opened 

5 Access channel closed 

Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

Frequency number for down frequency, i.e. 
the frequency on which BASE transmits. 



FOLLOWING. BLOCK 



No following blocks in this type 
of frame. 
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4.16 FRAME TYPE <TST>, Silence order 

APPLICATION Silence order is used by BASE to withdraw 
all access permissions during a free 
cycle- A MOB that is already transmitting 
may continue to do so, but for every other 
MOB the access permissions for all traffic 
types { emergency t speech and data) are 
withdrawn. 

Note: Please also refer to the description 
of the silence signal in reference 
Rl-17. This signal has the same 
meaning as the <TST>-frame but uses 
only the frame head and thus 
addresses ALL mobile terminals. 



PRIMARY BLOCK 



.1... L__l_ _1 1 1 

MOB 


1 1 1 1 1 1 1 

00010000 


33 34 35 36 37 38 39 40 
l 1 1— J 1 1 1 


41 42 43 44 45 46 47 48 


PRIO MASK 


BLOCK 



49 50 51 52 53 54 144 
1 I I 1—1 1 1 1 1 1 1 1 

oooooo oooooo 



PARITY 



No following blocks in this type 
of frame. 



AiS3 51S3.3 
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4.17 FRAME TYPE <AKT>, Activity request 

APPLICATION An <AKT> is used by BASE to check whether 
a aertain MOB is active. MOB replies with 
an <ACK> to such a £rame. 



PRIMARY BLOCK 



22 23 24 25 26 27 28 29 30 31 32 



1 1 1 L_ _l 1 1 1 

MOB 


0 0 


■o 


1 0 


0 


0 1 


33 34 
1 1 


35 36 37 
' I 1 


38 39 40 


41 42 


43 


44 45 


46 


47 48 

1 


0 0 


poo 


0 0 0 


BLOCK 


49 50 

,„ 1,;-, 


5152 53 


54 

- ...It- - 










144 


0 0 


0 0 0 


0 




0 


0 0 


0 


0 0 


145 










i 




160 


PARITY 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.18 FRAME TYPE <NAT>, No access permission, speech 

APPLICATION BASE replies with <NAT> to an <ABT> or a 
line connection request from a MOB when, 
for some reason, a line connection cannot 
be set up (e.g. no channel is available). 



PRIMARY BLOCK 

01 02 03 



J 1 1 1 1 



22 23 24 25 26 27 28 29 30 31 32 



10 0 10 



33 34 35 36 37 38 39 40 41 42 43 < 44 > 45 ^ 46 < 47 



000000 00 



49 50 51 52 53 54 55 56 57 



NATFL 
Bit 49 

50 - 56 



Contains the following orders: 
Leave CORRENT_BASE . 
Reserved 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.19 FRAME TYPE <BBT>, Change base station/ speech. 

APPLICATION BASE will use <BBT> 

- as a response to an <ABT> when another 
base station is to be used for the line 
connection 

or 

- to hand over a call in progress to 
another base station. 

PRIMARY BLOCK 

01 02 03 22 23 24 25 26 27 23 29 30 31 32 



1 1 1 _1 — 1 — 1 — 

MOB 


1 1 1 

0 0 0 


1 0 


_l 
0 


1 1 

1 1 


33 34 


35 


36 37 38 39 40 


41 42 43 


44 45 


46 


47 48 


1 1 " 


TIMEOUT _ 


BLOCK 


49 50 


51 


52 53 54 55 56 

■ i i i 


57 58 59 


60 61 


62 


63 64 
. I .J 


BBTFL 


65 66 


67 


68 69 70 71 72 

■ i i i 


73 74-75 


76 77 
i 


78 


79 80 


SPEECH DPFREQ 


81 82 


83 


84 85 86 87 88 


89 90 91 


92 93 


94 


95 96 


SPEECH DOFREQ 


97 98 


99 


100 




i 




112 
1 


BASE 


113 




■ i t i 


i i 






128 


NEW SYSTEM UPFREQ 


129 












144 

I I 


NEW SYSTEM DOFREQ 


145 






i i i 


i i 


1 , . 


160 
J 1 


PARITY 
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Bit 49 
50 



52 



If error, return after TIMEOUT seconds 
(1-255). 

Indicates the terminal is to act after 
changing to the new base station. 

Reserved 
Reserved 

After the call, use BASE as new current 
base station. 

After the call, return to old current 



53 Change and start the call set_up procedure 
from the beginning (new <ABT> on BASE). 

54 Change and continue (either signalling 
procedure or call in progress). 

55-64 Reserved 



BASE 
SPEECH OPFREQ 
SPEECH DOFREQ 
NEW SYSTEM tJBFHEQ 

NEW SYSTEM DOFREQ 



FOLLOWING BLOCK 



t base station to be 



Frequency number for 
transmitting speech. 

Frequency number for receiving 
speech. 

Frequency number for upwards 
traffic on 'the new system 
channel, i.e. the frequency on 
which the terminal transmits. 

Frequency number for downwards 
traffic on the new system 
channel, i.e. the frequency on 
which the terminal receives. 



No following blocks in this type 
of frame. 



This order is only valid if both BBTFL 3 and BBTFL 6 are 
raised, i.e. hand over of a call in progress. 

Other combinations of BBTFL are to be included in later 
versions. 
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4.20 FRAME TYPE <VKT>, Wait for channel, speech 

APPLICATION BASE replies with one (or more) <VKT>- 
frame(s) to an <ABT> from a MOB when a 
speech channel is not immediately 
available. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



MOB 


.. 1 
0 0 


L 

0 


, ,1 , 
1 0 


1 


1 ! 1 

0 0 


33 34 


35 36 37 


38 


39 40 


41 42 


43 


44 45 
i 


46 


47 48 
i 


|_ L.„. 

0 0 


0 0 0 


0 


0 0 


BLOCK 


49 50 


51 52 53 


54 


55 56 


57 58 


59 


60 61 
i 


62 


63 64 
i 


TIMEOUT 


QPOS 


65 66 
L L 


67 68 69 
1 1. ..J 


70 






I 






144 


0 0 


0 0 0 


0 






• 0 


0 0 


0 


0 0 


145 
1 


I 1 1 t 










1 





160 



If the mobile terminal has not received a 
<BKT> or a <NAT> within TIMEOUT seconds 
(0-255), the <VKT> is invalidated. 

States current position (1-255) in queue. 
It is recommended that this parameter is 
passed on to the application layer and 
shown to the operator. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.21 FRAME TYPE <AAT>, Cancel access request, speech 

APPLICATION HOB transmits an <AAT> when it wants to 

end a call and has been placed in a queue 
by BASE. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



1 1 1 III. 

MOB 


0 


-L 

0 0 


. J 
1 0 


1 


0 1 


33 34 


35 


36 37 38 39 


40 


41 


42 43 


44 45 
1 1 


45 


47 48 


0 0 


"0 


0 0 0 0 


0 


BLOCK 


49 50 

.. I 


51 

1 1 


52 53 54^55 


56 


57 






1 1 


144 


0 0 


0 


0 0 0 0 


0 


0 






0 


•0 0 


145 




1 1 — 1 — 1 — - 




1 


1 1 




- 


160 
1 I 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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5 CONVERTING A PACKET TO A FRAME 



<MRM>-fraraes conveys MPAKs ovar the radio channel. The 
primary block can accomodate 12 and each following block 
18 octets from the MPAK. 



HOB address 
Control field 



Parity field 



Next . 18 _ .. 
octets of MPAK 



Parity field 



iry b: 
with link layer 
information 



Following 
block #1 • 



Following 
block #n 



When converting a packet to a frame, the first 12 octets 
in the' packet shall be placed in the primary block of the 
frame. The last octets of the packet are placed in the 
last block. The primary block indicates how many octets in 
the last following block that are used. Unused octets in 
the last following block are filled with octets containing. 



In the primary block of the <MRM>-frame the Link Layer 
information is added. The MOB address field of the primary 
block shall always contain the MAN of the physical 
terminal concerned or, when the base station is 
transmitting to a group, the MAN of the addressed group. 
The base station identity is contained in the frame head 
preceding the primary block. 

The addresses in the MPAK itself indicates the sub- 
scriptions concerned (terminal, transferable or group). 
For packets to/from the terminal itself or its group 
numbers, the MOB address field of the primary block and 
the address in the MPAK are the same. For packets to/from 
a transferred subscription, the corresponding addresses 
differ. 
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6 BLOCK CODING 



6.1 GENERAL DESCRIPTION 

The code used is a cyclic block code for burst error 
control. The code message consists of 144 source data bits 
and a block check character [CRC, i.e. parity) of 16 bits, 
giving a total of 160 bits in a block. 

The generator polynomial defining the code is 

g(X) = X 16 + X 12 + X 5 +1 

i.e. CRC-CCITT X.25. 

The CHC is initialized to all ones, calculated from all 
the 144 source-data bits of the block and then its one's 
complement is transmitted. 

This code detects all (single) error bursts up to 16 bits 
in length and about 99,998% of all other error patterns. 



6.2 IMPLEMENTATION 

CRC calculations are customarily done in a multi-section 
shift register which feeds into an exclusive-OR gate whose 
output feeds back to other XOR gates located in between 
the sections of the shift register. The placement and 
quantity of XOR gates are defined by the generator 
polynomial. 

The CRC is then transmitted after the source data of the 
block. 

A logical arrangement identical to that used in the 
transmitter is also used in the receiver. Again the CRC- 
register is initialized to all ones, the CRC is calculated 
from the 144 source bits and its one's complement is 
compared to the received CRC. If thes are different an 
error has been detected. 

Instead of hardware logic a software algorithm may be 
used. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Rl-06, 7, 
Rl-09, 8 
Rl-17, 35 



31 
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ABSTRACT 

This document specifies the Physical Layer for mobile 
terminals connected to the MOBITEX network. 

The exchange of information between base radio station and 
mobile is done - by frames. A frame consists 'of a frame head 
and blocks. 

The frame head is added to the message sent by the Data 
Link Layer to establish synchronisation and identify the 
base station. It also includes a set of control flags. 

The blocks in a frame contain the data to/from the Data 
Link Layer plus parity bits - for error correction. 



A292 51SM 
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The protocol in the Physical Layer describes the way the 
mobile terminal handles the radio channel. The logical 
structure of the protocol is described in this document, 
while hardware-related functions such as: 

method of modulation 

suitable equipment for implementation 

requirements for the equipment 

are presented in reference Rl-18. 
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2 THE CHANNEL 



2.1 GENERAL CHARACTERISTICS 

The channel between the base radio station and the mobile 
terminal uses 

separate frequencies for transmission and reception, 
synchronous communication and 
frequency modulation (FM). 
It. is also affected by 

varying .field-strength, 

random errors and burst errors caused by fading and 
noise and -- - 

bit errors caused by ignition interference. 

Consideration has been given to these and other factors in 
the design of the protocol for the Physical Layer. 



2.2 FRAME STRUCTURE ' ' 

The exchange of information between base station and 
mobile is done by frames. A frame has the following 
structure: 



| Frame head | Block #1 | Block #2 | _ | Block ftn" 



The frame head is a very important part of the frame. It 
is added to the message sent by the Data Link Layer to 
establish synchronisation and identify the base radio 
station. 

The blocks in a frame contain the data to/from the Data 
Link Layer plus parity bits for error correction. 

When the number of blocks is zero, i.e. when only a frame 
head is sent, the term "signal" is used. 
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3 THE FRAME HEAD 



3 . 1 STRUCTURE 

The frame head has the following structure: 
01 02 03 04 05 06 07 08 09 .10 11 12 13 14 15 16 



1 1 1 1 1 1 1 1 1 1 1 L- ! 1 1 

BIT SYNCHRONISATION 


17 18 19 20 21 22 


23 24 25 26 27 28 


29 30 


31 32 


FRAME SYNCHRONISATION 


33 34 35 36 37 38 
-,. 1, I.. .J 1 


39 40.A1 42 43 44 


45 46 


47 48 


BASE IDENTITY 


j__J L 1. ..._J 1 

AREA IDENTITY ■ 


CTRL 


FLAGS 


49 50 51 52 53 54 
1 1 ,..,_!._.. 1 ,!_.,. 


55 56 
1 







PARITY BITS 



The different parts of the frame head are described in the 
following chapters. 
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3.2 SYNCHRONISATION 



3.2.1 Bit synchronisation 

This preamble is provided to enable bit sychronisation in 
the demodulator. It consists of 16 bits with the following 
pattern (bit #1 is. sent first): 

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 



10 0 11 



1100 1100 



1100110011 0 0 1 1 



from BASE 
from MOB 



3.2.2 Frame- synchronisation 

The frame synchronisation is provided to establish correct 
code word f raming. Each, network has its own pattern, used 
as network identification number, defined in reference Rl- 
06. In order to roam into base radio stations in other 
networks, it should be possible to manually change the 
frame synchronisation word from the application layer. 

It consists of 16 bits with the following structure, with 
bit #1 sent first: 

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 



xxxxxxxxx 



XXXXXXXXXX X X X X X X 



from BASE 
from MOB 



If there is more than 1 bit error in the detected pattern, 
then frame sync is not established. 

NOTE Only these 16 bits are used for frame 
synchronisation. 
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3.3 AREA IDENTITY, BASE IDENTITY AND CONTROL FLAGS 

The base identity (6 bits) and the area identity (6 bits) 
together, states the unique identity of the base radio 
station concerned. The most significant bit (01) in the 
addresses is sent first.. 

The base identity is followed by four control flags. They 
'are only used in traffic from BASE to MOB. The control 
flags are as follows (in order of reception): 



1 SA_flag 



Reserved for future use. 



2 Set_slot flag 0 = FALSE 

~ 1 = TRUE, reset slot clock. 

3 Roaming flag- 0 = FALSE 

~ 1 = TRUE, this is a roaming signal, i.e. 

it contains only a frame head. 

4 SilenceTflag" 0 « FALSE 

~ 1 = TRUE, this is a ..silence signal, i.e. 

it contains only a frame head.. 



BASE IDENTITY 



AREA IDENTITY 



CTRL FLAGS 



parity #2 , 



17 18 19 20 21 22 23 24 



The 8 (2*4) parity bits that follow the control flags are 
encoded in the same way as the blocks of the frame. Parity 
#1 is coded from octet #1 {see figure above) and parity #2 
from octet #2. 



The code corrects all single errors. In case- the frame 
head could not be corrected, it should be rejected. 

The parity bits may be ignored and the base identity and 
control flags read without any decoding. 
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4 ERROR CORRECTION AND DETECTION 



4.1 CODING 



Each block to/from the Data Link Layer contains 20 octets 
of information. These are put into a matrix of the 
following format: 



column — 1 2 3 4 5 6 7 8 9 10 11 12 . 



row 1 


octet 


#1 


parity 


2 


octet 


#2 








...... 


20. 


octet 


#20 





To each octet (column 1-3) four parity bits are added in 
the same row (9-12). These are encoded by a shortened 
(12,8) Hamming code. 

The code corrects all single errors with hard decision 
decoding . 



The code is defined by the following H-matrix: 
■ 11101100 1000 " 
11010011 0100 
10111010 0010 
01110101 0001 . 



The syndrome (s) is calculated from the received code word 
(v) by 



where H T denotes the transposed H-matrix. 
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The syndrome of a code word with a single error is equal 
to the columnvector of the H-matrix corresponding to the 
position of this error. The syndrome table is shown below. 



syndrome 


corresponds to 
a single error 
in bit position 


0 
1 


0000 0000 0001 


2 


0000 0000 0010 


3 
4 


0000 0000 0100 


5 


0000 0001 0000 


6 


0000 0010 0000 


7 


0001 0000 0000 


8 


oooo- 0000 1000 


9 


0000 0100 0000 


10 


0000 1000 0000 


' -11 - 


0010 0000 0000 


12 




13 


0100 0000 0000 


14 


1000 0000 0000 


15 





If the syndrome is 0 the code word is correct. 



The following examples illustrate the coding/decoding 
procedure: 



transmitted 
info parity 



1 0000 


0001 


0101 1 




1 0000 


0101 


1100 1 




| 0000 


0010 


0110 | 




| 0000 


0101 


1100 1 



received 

info parity 



0000 0001 0101 



0101 0101 1100 



0010 0010 0110 



0000 1111 1100 
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4.2 INTERLEAVING AND SCRAMBLING 

Before transmission the code is interleaved to give 
protection against burst errors. The block-matrix is sent 
columnwise with start at position (1,1) and is received in 
the same way. 

column — 1 2 3 4 5 6 7 8 9 10 11 12 



octet #1 


parity 


octet n 




• 




octet #20 





The., code .without interleaving can correct single errors.. 
The interleaved code can thus correct a burst of 20 
errors, assuming that there is no other error in the same 
block. 



Scrambling 

At transmission and reception the bits following the frame 
head should be added modulo-2 (exclusive-ored) with the 
output from the ninth stage of a binary nine-stage shift 
register. 

The outputs of the fifth and ninth stage of the shift 
register should be added modulo-2 and the result fed back 
to the input of the first stage. 

All bits in the shift register should be sent to the 
logical value 1 upon initialization for reception or 
transmission. 

That is, the bit3 following the frame head will be - 
exclusive-ored with the sequence: 

111111111000001111011111000101 , etc. 

This scrambling sequence is the recomended test sequence 
described in CCITT recommendation V.52 r as well as the 
shift register on the next page. 



Note: It should be possible, via a test command in MASC 
(reference Rl-19 ), to order the mobile to ■ 
start/stop sending the above described scrambling 
sequence. This should only be possible during test, 
not during normal operation. 
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Shift register stages during pseudo-random pattern 
generation. 




1 
1 


2 


3 


4 


I 

5 


6 


7 


a 


9 


Out 




1 


1 


1 


1 


1 


1 


1 


l 


1 


1 


0 


1 


1 


1 


1 


1 


1 


l 


1 


1 


0 


0 


1 


1 


1 


1 


1 


l 


1 


1 


0 


0 


0 


1 


1 


1 


1 


l 


1 


1 


0 


0 


0 


0 


1 


1 


1 


l 


' 1 


1 


0 


0 


0 


0 


0 


1 


1 


i 


1 ' 


1 




0 


0 


0 


0 


0 


1- - 


l 


1 


1 


1 


1 


0 


0 


0 


0 


0 


l 


1 


1 


1 


1 


1 


0 


0 


0 


0 


0 


1 


1 


1 


1 


1 


1 


0 


0 


0 


0 


0 


0 


0 


1 


1 


L 


1 


0 


0 


0 


0 


' 0 


1 


0 


1 


1 


1 


1 


0 


0 


0 


0 


1 


1 


0 


1 


1 


1 


1 


0 


0 


0 


1 


1 


1 


0 


1 


1 


1 


1 


0 


0 


1 


1 


1 


1 


0 


1 


1 


1 


1 


1 
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5 TIME DIVISION 



The time axis is divided into slots. The length (L) of one 
of these slots. is given by the parameter Slot_length. 



[slot n I slot n+1 [slot n+2 jslot n+3 | _ 

.+ + _ — + h + > t ime 

t t+L t+21. t+3L t+4L 



The mobile keeps a clack going to be able to detect slot 
boundaries. The start (tl) of the first slot in a sequence 
is defined by BASE transmitting a frame head with a 
Set_slot_flag»- 



[frame head) block #1 | 

to tl = to + 20 ms 



The first bit of the frame head is received at time to. 
Slot number n starts at: 

t= tl + (n-l)*L 

where 

L = .Slot_length * (32/bitrate) seconds 
n = l..x 



The tolerance for determining the start of a slot is 
-0.1/+3 ms. 
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6 TRANSMISSION 



When an order to transmit a frame (FRAME_TO_SEND) has come 
from the Data Link Layer, the Physical Layer first waits 
until the slot clock reaches the CH0SEN_SL0T (please also 
refer to chapter 8) before it: 

indicates SLOT_REACHED to the Data Link Layer 
switches the carrier on 

waits until carrier frequency and power has 
stabilized 

waits 5 ms (tolerance -OAS ms) 

sends frame head with base and area identity (from 
Current_base) and all control flags = 0 (i.e. FALSE) 
encodes and sends all blocks of the frame 



before it switches the carrier off and indicates 
FRAME_SENT to the Data Link Layer. If the order 
CANNOT SEND comes from the Data Link Layer before the 
CHOSEN_SLOT is reached, then the transmission will not be 
started. 
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7 RECEPTION 



The following takes place when correct bit and frame 
synchronisation has' been established: 

get average signal strength during reception of 

frame head *) 
send Received base to Data Link La yer 
IP received Ease = Current_base THEN 

IP Silence_flag THEN 

send Silence to Data Link Layer 



REPEAT 

read block 
decode block 

send Received block to Data. Link Layer . 
UNTIL Sync_search 



On reception of the order Measure_RSSI from the Data Link 
Layer, the average signal strength *) is measured during 
the time stated in the order. Thereafter an answer, 
RSSIjneasured, is sent to the Data Link Layer. 



*) The RSSI should be sampled with a frequency of 1000 
samples per second. 
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8 INTERFACE TO THE DATA LINK LAYER 



Parameters received from the Data Link Layer: 



Slot_length 

Chosen_slot 

Current_base 

Frame_to_serid 

Frame_length 
Sync_sear.ch 

Cannot_send 

Measure RSSI 



- states the length of a single slot. The 
unit is (32/bitrate) seconds. 

- states the slot where transmission 
starts. 

- states which base radio station is 
currently used (base and area identity). 

- is a message consisting of at least one 
block. 

- states the number of blocks in message. 



reading and enter sync search i 

- orders the Physical Layer not to send in 
any slot. 

- orders the Physical Layer to measure the 
' average received signal strength, during 

the time stated in the order. 



Parameters sent to the Data Link Layer: 



Frame_sent 

Received_block 
Received base 



Slot_reached 
RSSI Measured 



- indicates that a frame transmission is 
completed . 

- is a decoded block (w error indication). 

- states the base identity, area identity 
and the received signal strength in 
dBuV. 

- indicates that we have received a 
silence signal. 

- indicates the start of the Chosen_slot. 

- the average received signal strength, 
during in order Measure_RSSI stated 
time. 
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other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
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Mobile radio equipment 
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ABSTRACT 



This document specifies the requirements for the radio 
transmitter and receiver in the MOBITEX MOBILE TERMINAL. 

The document contains a functional description and a 
detailed specification of the technical requirements and 
performance .of the transmitter and receiver. 

The equipment specified in this document . should also meet 
with basic requirements set up in national regulations for 
radio transmitters and radio receivers. 

Environmental, power supply and operational control 
requirements are found in the document General 
Requirements for the Mobile Terminal. 
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1 INTRODUCTION 



1.1 GENERAL 

The radio transceiver serves as interface between the 
. radio path and the logic and control unit of the mobile 
. terminal. Data and voice transmission is provided. 

The transmission mode is semi-duplex, the base station 
operates in full duplex mode and the mobile station in two 
frequency simplex mode. 

Digital FM modulation is used for data transmission at a 
speed of 8 kbit/s. 

The channel spacing is 12.5 kHz. 
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2 FUNCTIONAL DESCRIPTION 



2.1 DATA TRANSMISSION 

The main traffic in the Mobitex network will be of the 
data transmission type. 

A modulation type which makes it possible to utilize the 
radio transceiver for speech transmission as well as for 
data transmission has been chosen. 

The modulation type is binary digital baseband filtered PH 
at a speed of 8 kbit/s. 

There should be no squelch function during data 
transmissions.. 



The data transmission mode is used for - transmission of 
system information, system orders and for the signalling 
between the base station and the mobile station as well as 
for the user data and text transmissions. 

The data transmission mode is basically a simplex mode, 
data transmission takes place only in* one direction at a 
time. Short switchover times are important as this will 
increase the system efficiency. 
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2.2 SPEECH TRANSMISSION 

The speech transmission mode is only reached after a 
request from either a mobile or a fixed terminal. 

After a request for speech communication the base station 
allocates a radio channel and sends an order "to the mobile 
station to switch over to that channel (separate, transmit 
and receive frequencies). 

No squelch function is to be used during speech 
communication. 

The muting of the audio paths is released during speech 
communication. If, however, a data signal is detected 
during the speech, the audio paths to be muted 
immediately. This will for example occur when a data 
message is received during ongoing speech conversation. 



2.3 TRANSMITTER CONTROL 
2.3.1 Frequency 

The transmitter frequency is controlled by the control 
unit. 

For information about frequency band and channel numbering 
plan to be used, please refer to document Rl-06. 



2.3.2 Carrier 

The carrier on/off condition is controlled by the control 
unit during data transmissions. During speech transmission 
the carrier on/off condition is controlled by the manually 
operated transmit/receive switch. 

Requirements of dynamic output power control can be made. 
In such a case, these are stated in reference Rl-06. 

There is to be a control circuit, independent of all other 
logic,, which prohibits the continuous transmission of 
carrier for longer periods than 10 minutes. 



2.3.3 Audio muting 

The voice signal to the transmitter to be "muted during 
data transmissions. 
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2.4 RECEIVER CONTROL 

2.4.1 Frequency " 

The receiver frequency is controlled by the control unit. 

For information about frequency band and channel numbering 
plan to be used, please refer to document Rl-06. 

2.4.2 Squelch control 

There must be no squelch function in the receiver. 



2.4.3 Signal strength indication 

The received signal strength level is used in the roaming 

algorithm for selection of base station. 

Please refer to chapter RECEIVER in this document which 

includes a specification of the signal strength 

indication. 

2.4.4 Audio muting 

Whenever a data signal is detected, e.g detection of frame 
synchronization, the receiver voice output should be 
muted. 
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3 PERFORMANCE AND TECHNICAL REQUIREMENTS 



3 . 1 GENERAL 

For definitions and measurement methods, please refer to 
Appendix A. 

3.1.1 Frequency range 

For information about which frequency band and channel 
numbering plan etc that will be used, please refer to 
document Rl-06. 

3.1.2 Frequency error 

• The frequency error of— the transmitter and receiver shall 
not exceed {+)(-) 1.5 ppm. 
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3.1. 3 Data transmission 
3.1.3.1 Modulator 



Logic 


Level 


NRZ 


Lowpass 




VCO 


seq. 


shifter 


waveform 


filter 





J 



Figure 1. Block diagram of the method' of modulation. 

The modulation type is binary digital baseband filtered FM 
at a speed of 8 kbit/s. The method of modulation is shown 
in principle in Figure 1. The logic sequence to transmit 
is converted to a binary NRZ waveform by a level shifter 
and the NRZ waveform is filtered by a lowpass filter with 
linear, phase-characteristic. 

The filtered waveform is applied as control incut to a 
VCO, a voltage controlled oscillator. The lowpass filter 
reduces the deviation of the modulator for the high- 
frequency components of the binary modulating signal and 
thereby reduces the out of band emission of the 
transmitter. 

A sequence of logic I's should yield a transmitter 
frequency 2.0 kHz higher than the channel center 
frequency, A sequence of logic O's should yield a 
transmitter frequency 2.0 kHz lower than the channel 
center frequency. That is the modulation index is 0.5. 

The filter (or the equivalent filter in case of an other 
implementation) shall be a low pass filter with linear 
phase characteristic and a 3-dB frequency of 2.4 kHz. At a 
frequency two {2} times the 3-dB frequency the attenuation 
of the filter shall be 12 dB, and at a frequency four (4) 
times the 3-dB frequency the attenuation of the filter 
shall be 48 dB. The high frequencv roll-off of the filter 
must be at least 40 dB/octave. A high frequency 
attenuation of 70 dB is considered sufficient. Figure 2 
shows the amplitude response of the filter. The frequency 
modulator should be of a wide band linear type with 
frequency independent response in the frequency range 0 - 
4 kHz or otherwise compensated in the baseband filter. 
An eye diagram of the transmitted signal is shown in 
Figure 3. 
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Figure 2. Amplitude response of lowpass filter. 




Figure 3. Eye diagram. 



A preferred implementation of the baseband processing is 
oversampling of the bit-stream 4-8 times and digital 
filtering in a FIR (finite impulse response) filter with 
symmetric coefficients. This type of imDlementation can be 
realized by simple table look-up in a PROM. 

The modulation rate is 8 kbits per second. The frequency 
error of the bitrate clock should not exceed. +-10 ppm. 
The error of the modulation index should not exceed +- 5 
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3.1.3.2 Demodulator 



The demodulator should be of non-coherent type. A simple 
decision feedback or sequence detector should be used to 
resolve the small receiver eye opening of two subsequent 
bit transitions. A required bit error rate (BER) curve as 
a function of receiver input in a static receiver noise 
limited situation is shown in Figure 4. 

The performance requirement of the complete receiving 
equipment when connected to a reference data transmitter 
is that the decoded block error rate should be less than 
0.1 at the reference RF input signal level. At an RF input 
signal level 30 dB above the the reference level, the 
decoded block error rate should be less than 0.0001. 

It is essential that the demodulator keeps the synchronism 
with the incoming bit-stream during an entire message, ' 
even under disturbed conditions, in order to avoid 
repetition of other blocks than those which were actually 
disturbed. - ■ - - • - 



BER 
1E-1 




115 112 109 Receiver input (-dBm) 

Figure 4. Bit error rate versus receiver input level. 
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3.1.3.3 Start of data modulation 

Data modulation must not start until the carrier frequency 
is within its 200 Hz from its steady state value and che 
carrier power is within 2 dB from its steady state value. 

The transmitter carrier should be on for 5 -0/+5 ms before 
the start of transmission (frame head). 



3.1.3.4 Receive/transmit switching times 

The switching time from receive to transmit condition to 
be less than 20 ms including CPU handling time. 

The switching. time from transmit to receive condition to 
be less than 20 ms including CPU handling time. 



3.1.4 Test terminals 

Please note that the transceiver input/output terminals 
for voice must be accessible. 

An interface according to the "machine interface" defined 
in reference Hl-19, must be available during testing. 



'3.1.5 Test modulation 

Short and long frames as defined in the link layer will be 
used during tests of data transmission. 

It should be possible to force the modem to continuously 
transmit a sequence as specified iri the national 
requirements for out of band emission testing. 

It should be also be possible to force the modem to 
continuously transmit the scrambling sequence that is 
specified in Physical Layer Specification of the mobile 
terminal. 

Normal audio test modulation is a 1 kHz test tone at such 
a level that the resulting deviation is +- 1.5 kHz. 
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3.2 TRANSMITTER 

For definitions and measurement methods, please refer to 
Appendix A. 



3.2.1 Carrier power 

The nominal output power is stated in reference Rl-06. 
Requirements of dynamic output power control can be made. 
In such a case, these are also stated in reference Rl-06. 

Under normal, test conditions and independent of selected 
channel the carrier output power during carrier on 
condition to be within "(+)(-) 1,5 da of the nominal output 
power. Under extreme test conditions the carrier output 
power to be within +2 dB and -3 dB of the nominal output 
power. 

When the transmitter is in the carrier off condition, the 
carrier output power should not exceed 0,25uW. 



The transmitter to be able to withstand load tests as 
described below: 

-the change in the transmitter output power should -not 
exceed 2 dB during a load test when. the transmitter is 
loaded with a resistive load giving a standing wave ratio 
of 2. The test to be done at normal test conditions 
during 5 minutes of continuous transmission. 

-without being damaged the transmitter should be able to 
withstand the same test at extreme test conditions. 



-without being damaged the transmitter should be able to 
transmit for a period of 1 minute with the antenna 
terminal left open. 

-the last mentioned test to be repeated with the antenna 
terminal short-circuit. 
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3.2.2 Carrier rise and 


fall time 




The carrier rise time and carrier fall time are included 
in tne transmit-receive and receive-transmit switching 
SSi ^nL^ocument? 113 ^" -Aching 




3.2.3 Channel switching time 




The channel switching time should not exceed 30 ms. 




3»2*4 Frequency dsviflfcion 




3.2.4.1 Maximum permissible deviation 




T+)(^)2 i ? U ifH| e '™ iaaible frequency deviat i°n to be 




3.2.4.2 - Data modulation 




A long sequence of logic l's (0's) should produce a 
carrier frequency deviation of + {-, for 0's) 2.0 kHz 
+- 0.1 kHz. 




3 • 2* 4.3 Audio modulation 




The normal audio test tone will produce a deviation 
of +- 1.5 kHz. 




3.2.4.4 Audio frequency response 




The audio frequency response, measured through the audio 
signal input terminal, should have a 6 dB/octave pre- 
eraphasis between 300 Hz to 2500 Hz. For frequencies higher 
than 3000 Hz, the frequency response should have a roll- 
off of at least 30 dB/octave. 
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Figure 5. 



Frequency deviation relative to 1 kHz at 
constant input level. 



3.2.5 Adjacent channel power 

The adjacent channel power should not exceed the value 
specified in the national technical requirements, in case 
such a value is specified in the national technical 
requirements. 

3.2.6 Harmonic distortion 

The harmonic distortion factor should not exceed 5%. 



3.2.7 Residual modulation 

The residual modulation should not exceed - 40 dB, 
• measured with a psophometric filter. 

The residual modulation should not exceed - 20 dB, 
measured without filter. 
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3.2.8 Modulation due to vibration 

The modulation due to vibration should not exceed -30 dB 
measured by a r.m.s. voltmeter and with a psophometric 
filter. 

Without the psophometric filter and measured by a peak-to- 
peak voltmeter the modulation should not exceed -14 dB. 



3.2.9 Audio muting 

An input muting device controlled by the control unit 
should be provided. The muting to be capable of causing at 
least 40 dB attenuation in the voice path. Data 
transmission is not to start until the muting has reached 
an attenuation of 40 dB. 



.•V23Z51S3.3 
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3 . 3 RECEIVER 

For definitions and measurement methods, please refer to 
Appendix A. 

3.3.1 Channel switching time 

The channel switching time should not exceed 30 ms 
including data signal detection time. 

3.3.2 Squelch opening and closing levels and delays 
There must be no squelch function in the receiver. 

3.3.3 Signal strength indication 

The signal strength to be indicated by the receiver to the 
control unit. 

The indicated range to be : 

RF-level . 0-50 dBuV eraf with a monotonic output 

and absolute accuracy of 

+-(2 +10 % of actual value) dBuV emf. 

The time constant to be 1 ms. 



3.3.4 RF sensitivity 

The receiver sensitivity (speech) not to exceed 0 dBuV emf 
under normal test conditions and + 4 dBuV emf under 
extreme test conditions . 



The reference signalling sensitivity (data) not to exceed 
0 dBuV emf under normal test conditions , and 3 dBuV emf 
under extreme test conditions. 

The multipath signalling sensitivity (data) must not 
exceed 12 dBuV emf. This measurement is oniy done under 
normal test conditions. • 
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3.3.5 Adlacent channel selectivity 




The receiver shall comply with applicable national 
technical requirements. 




3.3.6 Spurious respons 


e rejection 




■ The receiver shall comply with applicable national 
technical requirements. 




3.3.7 Co-channel reiection 




The measurement is made with the wanted signal at an input 
level of +10 dBuV emf . 




The co-channel rejection level at any frequency 
displacement of the unwanted signal within the specified 
range to be greater than -2 dBuV emf. 




3.3.8 Intermodulation 


response 




The receiver shall comply with applicable national 
technical requirements. 




3.3.9 Blocking 






The receiver shall comply with applicable national 
technical requirements. 




3,3.10 Amplitude characteristic of the receiver 




Por the specified change of radio frequency input level, . 
the change of the audio output level should not exceed 3 
dB between the maximum and minimum output levels. 




3.3.11 AM-suppression 






The AM-suppression should not be less than 30 dB. • 




3.3.12 Audio frecruency response 




The audio frequency response, measured at the audio output 
terminal, should be within the limits as shown in the 
figure below. 



AM251SJ3 
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300Hz 1000Hz 3000Hz 

Figure 6 . Audio power relative to 1kHz at constant 
frequency deviation. 

3.3.13 Harmonic distortion 

At all audio frequencies used in the measurement and under 
all test conditions the harmonic distortion factor should 
not exceed 5%. 



3.3.14 Noise and hum 

The receiver "noise and hum" ratio should not exceed -40 
dB measured by a- r.ra.s. voltmeter and with a psophoraetric 
filter. 

Without the psophometric filter and measured by a peak-to- 
peak voltmeter the "noise and hum" ratio should not exceed 
-20 dB. 
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3.3.15 Audio output due to vibration 

The noise and hum ratio of the receiver due to vibration 
should not exceed -30 dB measured by a r.m.s. voltmeter 
through a psophometric filter. 

Without the filter and measured by a peak-to-peak 
voltmeter the the ratio should not exceed -14 dB. 



3.3.16 Audio muting 

An output muting device controlled by the control unit to 
be provided. The muting device to be capable of causing at 
least 40 dB attenuation in the voice path. 
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4 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Rl-06, 6, 
Rl-19, 12 



7, 8, 13 



Below are the reference designations listed. 
Reference Section 



Rl-01 
Rl-02 
Rl-03 
Rl-04 
Rl-05 
Rl-06 
Rl-08 
Rl-09 
Rl-11 
Rl-12 
Rl-16 
Rl-17 
Rl-18 
Rl-19 
Rl-20 



Arrangement of the documents 
MOBITEX System description 
General description of terminals 
Terminology 
References 

Network operator information 
Application layer 
Network layer 

Interface requirements, fixed terminals 
Other requirements, fixed terminals 
Link layer, mobile terminals 
Phys i cal laye r , • mob i le te rmi nals 
Radio equipment, mobile terminals 
Other interfaces, mobile terminals 
Other requirements, mobile terminals 
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Appendix A, Measurement methods 



1 INTRODUCTION 

This document is an Appendix to MOBITEX TERMINAL 
SPECIFICATION - RADIO EQUIPMENT. It consists of 
requirement definitions and measurement method 
descriptions. 

The measurement values applies to 12,5 kHz channel spacing 
in the 900 MHz frequency band. 

The document describes measurement methods for several 
data transmission speeds. Therefore, measurements without 
specified requirement procedures in the main document can 
be found. These should be ignored. 

The equipment specified in this document should also meet 
with basic requirements set up in national regulations for 
radio transmitters and radio receivers. 
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2.1 SYSTEM MEASUREMENTS 



2.1.1 Receive to transmit switching time 
Definition: 

The switching time from receive to transmit condition is 
defined as the elapsed time from the end of an incoming 
frame with the response flag set, to the beginning of the 
response, i.e. the data signalling starts (see main 
document "Start of data modulation" ) . 

2.1.2 Transmit to receive switching time 
Definition: 

The switching time from transmit to receive condition is 
defined as the elapsed time from end of the last frame in 
a message sent by the transmitter, until the receiver is 
capable of detecting incoming data sighals. 

2.1.3 - Channel switching time 
Definition: 

The channel switching time is defined as the elapsed time 
from the end of a received order to change channel, until 
the receiver is capable of detecting data signals on the 
new channel. 



2.1.4 Frequency error 
Definition: 

The frequency error of the transmitter is the difference 
between the measured carrier frequency and its nominal 
value . 

Method of measurement: 

The carrier frequency should be measured in the absence of 
modulation with the transmitter connected to an artificial 
antenna. 

The test should be made under normal and extreme test 
conditions. 
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2.2 TRANSMITTER MEASUREMENTS • 




2.2.1 Carrier power 






Definition: 






The transmitter carrier power is the mean power delivered 
to the artificial antenna during a radio frequency cycle 
in the absence of modulation. 




Method of measurement: 






The transmitter should be connected to an artificial 
antenna and the power delivered to this artificial antenna 
should be measured. 




The measurements should be made under normal and extreme 
test conditions.- 




2.2.2 Maximum permissible freouency deviation 
Definition: 




The frequency deviation is the maximum difference between 
the instantaneous frequency of the modulated radio 
frequency signal and the carrier frequency in the absence 
of modulation. 




Method of measurement: 






The frequency deviation should be measured at the output 
of the transmitter connected to an artificial antenna, by 
means of a deviation meter capable of measuring the 
maximum deviation, including that due to any harmonics and 
interraodulation products which may be generated in the 
transmitter. 




2.2.3 Audio frequency response 




Definition: 






The audio frequency response is the frequency deviation of 
the transmitter carrier as a function of modulation 
frequency at a constant level of the modulation signal. 




Method of measurement: 










A modulation signal at a frequency of 1000 Hz and adjusted 
to such level that a frequency deviation of (+)(-)0,5 kHz 
is obtained, is applied to the transmitter. The frequency 
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of the modulation signal is then varied between 300 Hz and 
25 kHz, its level being <cept constant. The connection 
values of frequency deviation and modulation frequency 
should be determined. 



2-2.4 Adjacent channel power 
Definition: 

The adjacent channel power is that part of the total power 
output of a transmitter under defined conditions of 
modulation, which falls within a specified Dassband 
centred on the nominal frequency of either of the adjacent 
channels. This power is the sum of the mean power produced 
by the modulation, hum and noise of the transmitter. 



Method of measurement: 

The adjacent channel power should be measured with a power 
measuring receiver which fulfills the requirements given 
in the CEPT recommendation T/R 24-1. The transmitter 
should be operated at the nominal carrier power under 
normal test conditions. The output of the transmitter 
should be linked to the input of the receiver by 
connecting device such that the impedance presented to the 
transmitter is 50 ohms and the level at the "receiver- 
input is appropriate. 

The transmitter should be modulated with a signal of 1250 



The signal of 1250 Hz should be adjusted to a level 20 dB 
higher than that required to produce (+}(-)l,5 kHz 
deviation. The "receiver" should be tuned to the nominal' 
frequency of the transmitter and the variable attenuator 
in the "receiver" should be adjusted to a vaiue p dB such 
that a meter reading of the order of 5 dB above the 
"receiver" noise level is obtained. 

The "receiver" should then be tuned to the nominal 
frequency of one of the adjacent channels and the variable 
attenuator should be adjusted to a value q dB such that 
the same meter reading is obtained. 

The measurement should be repeated with normal data test 
modulation (paragraph Test modulation, in the Main 
document ) . 

The ratio of adjacent channel power to carrier Dower is 
the difference between the attenuator settings p and q. 
The adjacent channel power is determined by applying this 
ratio to the carrier power. 
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2.2.5 Harmonic distortion 
Definition: 

The harmonic distortion factor of a transmitter modulated 
by an audio frequency signal is defined as the ratio, 
expressed as a percentage, of the r.m.s. voltage of all 
the harmonic components of the fundamental audio frequency 
to the total r.m.s. voltage of the signal after linear 
demodulation. 

With the method described below, when a distortion meter 
is used, the hum and noise components are included in the 
distortion measurement. 



Method of. measurement:.--— 

The radio frequency signal produced by the transmitter is 
applied, by means of a suitable coupler, to a linear 
demodulator equipped with a de-^emphasis network of 6 dB 
per octave. 

The radio frequency signal to be modulated successively at 
frequencies of 300, 500 and 1000 Hz frequency to (+)(-}1.5 
KHz deviation. 

The harmonic distortion factor of the audio frequency 
signal is measured at all the frequencies given above. 



2.2.6 Residual modulation 
Definition: 

The residual modulation of the transmitter is the ratio, 
expressed in dB, of the audio frequency noise level 
produced after radio frequency signal demodulation, in the 
absence of modulation, by the wanted signal, by the 
spurious effects of the power supply system, by the 
modulator or by other causes, to the audio frequency level 
produced by normal test modulation applied to the 
transmitter. 

Method of measurement: 

a) The normal test modulation is applied to the 

transmitter. The RP signal produced by the transmitter 
is applied by means of a suitable coupler to a linear 
demodulator. 
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The demodulator is equipped with a de-emphasis network 
of 6 dB per octave. 

All precautions .should be taken to prevent the 
measurement results from being affected by emphasis at 
the low audio frequencies of the internal linear 
demodulator noise. 

Measurements to be carried out on the demodulator 
output signal by means of an r.ra.s. voltmeter equipped 
with psophometric filter network described in CCITT 
Recommendation P. 53 .A. 

The modulation is then removed and the level of the 
residual audio frequency output signal is again 
measured. 

b) The same method as a) above but without the 
psophometric filter at the output. 

-.-JLti.fc.his case .the measurements are carried out by means 
of a peak-to-peak voltmeter. 



2.2.7 - Modulation due to vibration 
Definition: 

Modulation due to vibration denotes the ability of the 
transmitter to withstand influence on the radio frequency 
output signal by mechanical vibrations. 



Method of measurement: 

The residual modulation is .measured in accordance with 
5.2.2. The transmitter should during the test be vibrated 
in each of three directions: 

10 - 100 Hz 1 ra/s 2 

sweep rate 1 octave per minute 
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2.3 RECEIVER MEASUREMENTS 



2.3.1 RF sensitivity 
Definition: 



The maximum usable sensitivity of the receiver is the 
minimum level of signal (emf) and field-strength 
respectively at the receiver input, at the nominal 
•frequency of the receiver, with normal test modulation 
which will produce: 

an audio-frequency output power of at "least 50% of the 
rated power output and 

a SND/ND ratio (S=signal, N=noise, D=distortion) of 20 dB, 
measured at the receiver output through a telephone 
psophometric weighting network as described in CC1TT 
Recommendation P.53-A. 

Note: The characteristics of the 1" kHz band-stop filter 
used in SND/ND measurements should be such that at 
the output the attenuation at 1 kHz will be at least 
40 dB and at 2 kHz will not exceed 0.6 dB, The 
filter characteristics should be flat within 0.6 dB 
over the ranges of 20 Hz to 500 Hz and 2 kHz to 4 
kHz. In the absence of modulation of the total noise 
power at the audio-frequency output of the receiver 
under test. 

The reference signalling sensitivity data is the level and 
field-strength respectively of a radio frequency input 
signal at the nominal receiver frequency and modulated 
with the normal coded test signal or pseudo- random bit 
sequence which will produce a successful calling ratio of 
80% for signalling systems with a specific response as 
output and a bit error ratio of 0.01 for. data transmission 
systems with a bit stream as output respectively. 

Measurement methods: 

A signal of carrier frequency equal to the nominal 
frequency of the receiver and with normal test modulation 
shall be applied to the receiver input terminals. An audio 
frequency output load and a distorsion factor meter 
incorporating a 1 kHz band-stop filter and a psophometric 
telephone weigthing network shall be connected to the 
receiver output terminals. Where possible, che receiver 
volume control shall be adjusted to give at lease 50% of 
the rated output power. The test signal input level shall 
be reduced until a SND/ND ratio of 20 dB is obcained. The 
test signal input level under these conditions is the 
maximum usable sensitivity. The measurement shall be made 
under normal test conditions and extreme test conditions. 
Under extreme test conditions, a variation of the receiver 
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output power of (+){-) 3 dB from the value obtained under' 
normal test conditions may be allowed. 

A signal of carrier, frequency equal to the nominal 
frequency of the receiver and modulated with the normal 
coded test signal or a psuedo-random bit sequence shall be 
applied to the receiver input terminals. The level of this 
signal shall be such that a successful calling ratio of 
SCR = 80%, and a bit error ratio of BER =0.01 respective- 
ly is obtained. The reference signalling sensitivity 
(data) is the maximum level of the levels recorded for SCR 
= 80% and BER = 0.01. 

The multipath signalling sensitivity is the rms value of 
the level of a Rayleigh fading input signal at the nominal 
receiver frequency and modulated with the normal coded 
test signal or pseudo-random bit sequence which will 
produce a sucessful calling ratio of 80% and a bit error 
rate of 0.01. The measurements shali be carried out with a 
Rayleigh fading simulator set for a simulated vehicle 
speed of 90 km/h and repeated for , a simulated vehicle 
speed of 50 km/h and 10 km/h. The reference multipath 
signalling sensitivity (data) is the maximum neccessary 
level of the multipath measurements. 



2.3.2 Adjacent channel selectivity 
Definition: 

The adjacent channel selectivity is a measure of the 
capability of the receiver to receive a wanted modulated 
signal without exceeding a given degradation due to the 
presence of an unwanted modulated signal which differs in 
frequency from the wanted signal by an amount equal to the 
adjacent channel separation, for which the equipment is 
intended. 

Method of measurement: 

Two signals should be applied to the receiver via a 
combining network. The wanted signal should be at the 
nominal frequency of the receiver and be modulated with 
normal test modulation. The unwanted signal should be at 
the nominal frequency of the upper adjacent channel and be 
modulated with a 400 Hz tone to a frequency deviation of 
(+)(-)l,5 kHz. 

Initially the unwanted signal should be switched off and 
the level of the wanted signal should be adjusted to 6 
dBuVemf. The unwanted signal should then be switched on 
and its level adjusted until the SND/ND ratio, measured at ■ 
the receiver .line output terminal through the psophometric 
filter,- is reduced to 14 dB. 



1 
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The measurement should be repeated with the unwanted 
signal at the nominal frequency of the lower adjacent 
channel . 

The adjacent channel selectivity should be expressed as 
the lower value of the receiver input levels in dBuV emf 
of the unwanted signal for the upper and lower adjacent 
channels . 



2.3.3 Spurious response rejection 
Definition: 

The spurious response rejection is a measure of the 
capability of the receiver to discriminate between the 
wanted modulated signal of the nominal "frequency and an 
unwanted signal at any other frequency at which a response 
is obtained. 



Method of measurement: 

Two input signals should be applied to the receiver via a 
combining network. The wanted signal should be at the 
nominal frequency of the receiver and be modulated with 
normal test modulation. Initially the unwanted signal 
should be switched off and the wanted input signal 
adjusted to 6 dBuV emf. The unwanted signal should be 
switched on and modulated with a 400 Hz tone to a 
frequency deviation of (+)(-)l,5 kHz. The input level of 
the unwanted signal should be 86 dBuV emf and its 
frequency should be varied at least from 100 kHz to 2000 
MHz . 

At any frequency at which a response is obtained, the 
input level of the unwanted signal should be adjusted 
until the SND/ND ratio, measured at the line output 
terminal of the receiver ..through the psophoraetric filter, 
is 14 dB. 

The spurious response rejection should be expressed as the 
level in dB of the unwanted signal relative to 1 uV emf 
at the receiver input when the SND/ND ratio of 14 dB, as 
mentioned above, is obtained. 



2.3.4 Co-channel rejection 
Definition: 

The co-channel rejection is a measure of the capability of 
the receiver to receive a wanted modulated signal without 
exceeding a given degradation due to the presence of an 
unwanted modulated signal, both signals being at the 
nominal frequency of athe receiver . 
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Method of measurement: 



Two input signals should be applied to the receiver via a 
combining network. The wanted signal should have normal 
test modulation. The unwanted signal should be modulated 
with a frequency of 400 Hz to a frequency deviation of 
(+)(-) 1,5 kHz. Both input signals should be at the nominal 
frequency of the receiver and the measurement should be 
repeated for displacements of the unwanted signal up to 
(+)(-)l/5 kHz offset frequency of the nominal frequency. 

Initially the unwanted signal should be switched off and 
the level of the wanted signal should be adjusted to +6 
dBuV emf.The unwanted signal should then be switched on. 

The level of the unwanted signal should be adjusted until 
the SND/ND ratio, measured at the line output terminal of 
the receiver through the psophometric filter, is reduced 
to 14 dB. 

The. co-channel rejection should be expressed as the ratio 
in dB of the level of the unwanted signal to the level of 
the wanted signal at the receiver input for which . SND/ND = 
14 dB at the receiver line output terminal occurs. 



2.3.5 Intermodulation response 



Definition: 

The intermodulation response is a measure of the 
capability of the receiver to receive a wanted modulated 
signal without exceeding a given degradation due to the 
presence of two or more unwanted signals with a specific 
frequency relationship to the wanted signal frequency. 



Method of measurement: 

Three signal generators. A, B and C, should be connected 
to the receiver via a combining network. 

The wanted signal, represented by signal generator A, 
should be at the nominal frequency of the receiver and 
should have normal test modulation. 

The unwanted signal from signal generator B should be 
unmodulated and adjusted to the frequency separated by 25 
kHz above the nominal frequency of the receiver. 

The second unwanted signal from signal generator C should 
be modulated with a frequency of 400 Hz with a deviation 
of 1,5 kHz and adjusted to the frequency 50 kHz above the 
nominal frequency of the receiver. 




Exhibit 2, p. 



Cantel Mobitex- 



A/1056 - A 296 5173/01 Ue 



The amplitude of the wanted input signal should be 
adjusted to 6 dBuV emf . The amplitude of the' two unwanted 
signals should be maintained equal and should be adjusted 
until the SND/ND ratio at the receiver output, . 
psophometrically weighted, is reduced to 14 dB. 

The frequency of signal generator B should be adjusted 
slightly, if necessary, to produce the maximum degradation 
• of the SND/ND ratio. The level of the two unwanted test 
signals should be readjusted to restore the SND/ND ratio 
of 14 dB. 

The measurement should be repeated with the unwanted 
signal B at 2S kHz below that of the wanted signal and the 
frequency of the unwanted signal C at 50 kHz below that of 
the wanted signal. 

The intermodulation response level is the receiver input 
level in dB produced by each of the two unwanted Signal 
generators relative to 1 uV emf. 



2.3.6 Blocking 
Definition: 

Blocking is- a change (generally a reduction) in the wanted 
output power of a receiver or a reduction of the SND/ND 
ratio due to an unwanted signal on another frequency. 

Method of measurement: 

Two input signals should be applied to the receiver via a 
combining network. The wanted signal should be at the 
nominal frequency of the receiver and should have normal 
test modulation. Initially the unwanted signal should be 
switched off and the input level of the wanted signal 
should be adjusted to 6 dBuV emf. 

The output power of the wanted signal at the line output 
terminal of the receiver should be adjusted to the nominal 
output level. Then the unwanted signal should be switched 
on. The unwanted signal should be unmodulated, and its 
frequency should be varied between +1 MHz and +10 MHz, and 
also between -1 MHz and -10 MHz, relative to the nominal 
frequency of the receiver. The input level of the unwanted 
signal, at all frequencies in the specified ranges, should 
be so adjusted that the unwanted signal causes: 

a) a reduction of 3 dB in the audio frequency output power 
of the wanted signal, 

or 

b) a reduction of the SND/ND ratio to 14 dB, measured 
.through a psophometric filter. 
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whichever occurs first. 



This input level is the blocking level" at the frequency 
concerned. 



2.3.7 Amplitude characteristics 
• Definition: 

The amplitude characteristics of the receiver is the 
relationship between the radio frequency input level of 
specified modulated signal and the audio-frequency level 
at the receiver output. 



Method of measurement: 

A test signal at a level of 6 dBuV emf at the nominal 
frequency of the receiver and having normal test 
modulation should be applied to the receiver input. The 
audio frequency power at the line output should be 
adjusted to the nominal level. The input signal should be 
increased to 100 dBuV emf, and the audio frequency output 
level should again be measured. 



2.3.8 AH-suppression 
Definition: 

AH-suppression is the capability of the receiver to 
suppress amplitude modulated signals. It is expressed as 
the ratio in dB of the audio power at the line output 
terminal with normal test modulation to the audio power 
with a specified amplitude modulation. 



Method of measurement: 

A test signal at a level of 20 dBuV emf and 60 dBuV emf at 
the nominal frequency of the receiver to be applied to the 
receiver input successively. The signal should initially, 
have normal test modulation and the voice output terminal 
power should be set to the nominal output level. The 
normal test modulation should then be replaced by 
amplitude modulation to 30% with a 1000 Hz tone. The audio 
power should again be measured. It may be necessary to 
make this measurement with a selective voltmeter. 



2.3.9 Audio frequency response 
Definition: 
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The audio frequency response of the receiver expresses the 
variation in the audio- power at the line output terminal 
as a function of the modulation frequency of the input 
signal. 



Method of measurement: 

A test signal at a level of 60 dBuV emf at the nominal 
frequency of the receiver and having normal test 
modulation to be applied to the receiver input. 

The audio power to be adjusted to 50 % of the rated output 
power. This setting is not to be altered during the test. 

The frequency deviation at 1000 Hz then should be reduced 
to (+)(-)0,5 kHz and maintained constant while the 
modulation frequency is varied at least between 300 Hz and 
5000 Hz. 

--The~"measu'rement is repeated with the test signal- - 
successively at plus and minus 1,25 kHz from the nominal 
frequency' of the receiver . 



2.3.10 Harmonic distortion 
Definition: 

The harmonic distortion factor at the voice output 
terminal of the receiver is defined as the ratio, 
expressed as a percentage, of the r.m.s. voltage of all 
the harmonic components of the fundamental audio frequency 
to the total r.m.s output voltage. 

With the method of measurement described below in case a 
distortion meter is used, the hum and noise components are 
included in the distortion measurement. 



Method of measurement: 

Test signals of 60 dBuV emf and 100 dBuV emf at the 
nominal frequency of the receiver should be applied 
successively to the receiver input. 

In each measurement the audio power at the voice output 
terminal should be adjusted to the nominal output level. • 

The test signal to be modulated successively with 300, 500 
and 1000 Hz tones to (+)(-) 1,5 kHz frequency deviation 
and the harmonic distortion is measured at each frequency. 

Dnder extreme test conditions, tests to be carried out at 
the nominal frequency of the receiver as well as at plus 
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and minus 1,25 kHz from the nominal frequency. In. this 
case the input signal is modulated only. with a 1000 Hz 
tone to a ftequency deviation of (+){-) .1,5 kHz. 

2.3.11 Noise and hum 
Definition: 

The "noise and hum" of the receiver is the . ratio, expressed 
in decibels, of the. audio frequency noise and hum level 
resulting from the spurious effects of the power supply 
system or from other causes to the audio frequency level 
produced by RPrsignals as specified below and applied 
to the receiver input. 

Method of measurement: 

a) A test signal at a level of 30 dBuV emf at the nominal, 
frequency of the receiver and having normal test 

modulation, should be applied to the receiver input.' A' 

psophometric filter to be connected at the voice output 
terminal. The audio power to be adjusted to nominal 
level. 



The modulation is then removed and the audio power 
measurement is repeated. 

i The same method as in case a) above, but without the 
psophometric filter and using a peak-to-peak voltmeter 
for the measurement. 



2.3.12 Audio output due to vibration 
Definition: 

Audio output due to vibration denotes the ability of the 
receiver to withstand influence on a received radio 
frequency signal by mechanical vibrations. 

Method of measurement: 

The noise and hum of the receiver is measured in. 
accordance with 5.3.6. The receiver should during the test 
be vibrated in each of 3 directions. 

10 - 100 Hz 1 m/s 2 

sweep rate 1 octave per minute 
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During the vibration the radio frequency test signal 
should be unmodulated and the level of the receiyer output 
signal should be measured. 
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2.4 MEASUREMENT ACCURACY 






The measurement instrumentation should have at least the 
accuracy given below: 


D.C voltage 




+ 


t")l% 


A.C mains voltage 




+ 


M3t 


A.C mains frequency 




( + 


(-)0,5% 


Audio- frequency voltage. 


power, etc. 


+ 


(-)0,5 dB 


Audio-frequency 




+ 


(-)0,1% 


Distortion and noise, etc of audio 
frequency generators 


+ 


M0,3% 


Radio frequency 




+ 


(-)20 Hz 


Radio frequency voltage 




+ 


(-)2 dB 


Radio- frequency field strength 




(~)3 dB 


Radio-frequency carrier power 


+ 


(~)5% 


Impedance of artificial loads, 
combining units,, cable, plugs, 
attenuators, etc. 


+ 


(")5% 


Source impedance of generators and 
input impedance of measuring receivers 


+ 


(-)10% 


Attenuation by attenuators 
Temperature 


+ 
+ 


(-)0,5 dB 

(-)i 6 c 


Humidity 




+ ] 


t-)5% 


Time 




+ ) 


(-)10% 



A232S1SM 
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Other interfaces, mobile terminal 
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ABSTRACT 

This document specifies the interfaces between the MOBITEX 
network and a mobile or fixed terminal connected to the 
network. 
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1 INTRODUCTION 
1.1 GENERAL 

The purpose of this specification is to give well defined 
interfaces for the connection of application equipment. This 
specification will serve as a recommendation for the mobile 
terminal market. 

NOTE; The Radio/MCO must be type-tested with a terminal of 
"masc" type. A minimum number of commands (defined by 
document Mobitex ASyncronous Communication, APPENDIX 
A, Commands) are then required. 
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2 GENERAL DESCRIPTION 

The picture belaw shows the mobile terminal system parts. 



MOBILE TERMINAL 



AUDIO-EQUIPMENT | 



"j OP-TERMINAL 



MOBILE TERMINAL s complete equipment 
MCU : mobile control unit 

AUDIO-EQUIPMENT : equipment like mic/speaker , handset 
OP— TERMINAL : terminal for operators 

EMERGENCY EQU. : equipment like emergency receiver, emergency 
button 

2.1 Terminal interface 

Asynchronous, serial data transmission. Permitted transmission 
rates are 600, 1200, 2400, 4800 and 9600 Baud. However, for 
"masc" type terminals 600 baud is not permitted. Default value 
is 1200 Baud. In MCU it must be possible to set any of these 
baud .rates by hardware switches or alike. It must be possible 
to set the baud rate of each -output separately. Normally 1 
start bit, 8 data bits, 1 stop bit and no parity is used. 
However, masc type terminals should use 7 data bits and even 
parity. 

2.1.1 Printer/data collection unit 

Interface designed to connect a printer or any other character 
(text) oriented terminal. It can also be used for data 
collection units. This interface must be combined with one or 
more of the other terminal interfaces. The 7 most significant 
bits are coded according to MOBITEX TEXT CODE, see reference 
Rl-06. The eighth bit is set to logical zero. 
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2.1.2 Terminal with small display 

Designed for connection to a unit with a limited text display 
area and from which the. operator can enter numbers, status 
messages and text including simple text editing. The editor is 
placed in MCO. Also the audio equipment and the manual mode of 
the radio equipment can be handled from this unit. Character 
oriented format {as above) is used. 



2.1.3 ANSI terminal 

For connection of asynchronous full screen terminal which 
complies with terminal interface ANSI X 3.41 1964 and 
ANSI X 3.64 1979 with respect to cursor control and editing 
functions . 

Prom. the terminal the operator can enter numbers, status 
messages and text including text editing. The editor is placed 
in MCU. Character oriented format as above. 



2.1.4 "MASC" type terminal 

Connection of units with the capacity to handle complete data 
packets (MPAK) , e.g. a personal computer. The format is block 
oriented which means that information is' transmitted in the 
form of packets (MPAK) according to the format which is given 
in the network layer specification. Control of the complete 
mobile terminal, e.g. audio equipment and manual mode, is 
performed by special commands included in the protocol. The 
interface also contains functions for reading status parameters 
in the mobile terminal (meant for the type test). 7 bits per 
character and even parity to be used. Permitted transmission 
rates, are 1200, 2400, 4800 or 9600 Baud. 

For type testing, a masc type interface is required. In this 
case it may be implemented by external adaptors. 



2.2 Audio interface 

Connection of microphone and loudspeaker or handset. The 
interface also contains certain control functions. The handset 
can be combined with numeric and status keys. The same 
character codes as for the terminal with small display are 
used. The audio interface can also be combined with the 
terminal interface. Refer also to the application examples. 



2.3 Emergency interface 

Connection facilities for four units. Three connections are for- 
emergency buttons and one is for a receiver for receiving 
emergency transmissions generated by a portable transmitter. 
Any of these units can initiate the emergency procedure in MCU. . 
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3 TERMINAL INTERFACE 

This chapter describes the interface to equipment which 
communicates with MCO in serial form. 



3.1 PHYSICAL INTERFACE 

The physical interface is the same for all terminal types. 

The terminal interface uses a 25-pole DSOB socket (female 
socket with pins) with the following configuration: 



PIN 


V.24/V.28 


V.10 category 1/V.ll 


SOURCE 


1 


supply ground 


supply ground 






2 


transmitted data 


transmitted data 


A 


DTE 


3 
4 


received data 
* 


received data 


A 


1 MCU 


5 
6 


data set ready 


data set ready 


A 


MCU 


7 


signal ground 


signal ground 






8 




data terminal ready 


B 


DTE 


9 


system start (ground 


system start (ground) 


DTE 


10 


system start (+12V) 


system start (+5V) . 




DTE 


11 




* 






12 


* 








13 


* 








14 




transmitted data 


B 


DTE 


15 




received data 


B 


MCU 


16 .. 




* 






17 




* 






18 




data set ready 


B 


MCO 


19 










20 
21 


data terminal ready 


data terminal ready A 


DTE 


22 


ring ind. 


ring ind. 




MCO 


23 




* 






24 


-12V (supply) 


* 




MCU 


25 


+12V (supply) 


+5V (supply) 




MCU 



Fins 9, 24 and 25 differ from V.28; Pins 9, 10, 24 
and 25 differ from V.24. 

The following applies to V10: 0 or ON is when A > B 
and 1 or OFF is when B > A. 



The following applies to V28: 0 or ( 
and 1 or OFF is when V < -3V. 



is when V > 3V 
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The transmission rate for serial data is 600, 1200, 
2400, 4S00 or 9600 baud. 

The signal "DATA SET READY" is activated as soon as 
HCO is ready to transmit. The signal to be activated 
when it is not used. 

An active signal means that the physical layer is in 
the data transmission mode. 

System Start, activating MCD from equipment not 
according to V.28. 

MCD starts up within 10 seconds when pin 9 is 
activated (ON condition) . MOT then remains on until 
all system start signals are inactivated. 
ON conditions voltage 0V - +1V; current less 

than 5 mA. 
OFF -condition: not connected or 

voltage +2V - +15V: current less 

than 5 mA. 

System Start, activating MCD by signal according to 
V.28. 

MCD starts up within 10 seconds when pin 10 is 
activated. MCU then remains on until all system 
start signals are inactivated. • 
ON condition: voltage > 3V (see V28). 

OFF condition: not connected or 

voltage < -3V. (see V28). 

The signal "DATA TERMINAL READY" is activated as 
soon as the terminal is ready to receive. The signal 
is to be activated when not used. 

An active signal means that the physical layer is in 
the datatransmission mode. 

The signal "RING INDICATION" is used to activate the 
periferal unit. 

- 12 V/100 mA supply for connected equipment. 

+ 12 V (+ 5 V)/500 mA supply for connected 
equipment . 
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3.2 PROTOCOL FOR PRINTER/DATA COLLECTION UNITS 



General 

Interface designed to connect a printer or any other character 
(text) oriented terminal. It can also be used for data 
collection units. This interface must be combined with one or 
more of the other terminal interfaces. 



Receiving text 



To stop the data stream from MCO temporarily, the printer sends 
XOFF (DC3) to MCO and to restart the data stream it sends XON 
(DC1). 



Sending text 

Text can be sent to MCO. In MCO a complete MPAK will be created 
with sender and addressee before it is transmitted on the radio 
path. 

The connected unit stops sending when it has received XOFF 
( DC3 ) from MCO and does not start again until XON (DC1) is 
received. 
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3.3 PROTOCOL FOR TERMINALS WITH SMALL DISPLAY 



3.3.1 Receiving data 

To stop the data scream from MCU temporarily , the terminal 
sends XOFF (DC3) and to restart the data stream it sends XON 
(DG1). Received characters in the code range 32 - 126 (decimal) 
are printed out directly. Other codes are interpreted by che 
terminal according co the following table: 



CHARACTER CODE 


TERMINAL S INTERPRETATION Uf 


000 


NUL 




001 


SOH 




002 


STX 




003 


ETX 




004 


EOT 


- 


005 


ENQ 




006 


ACK 




007 


BEL 


give audible signal 


008 


as 


move cursor one step to left 


009 


HT 




010 


LF 


line feed 


011 


VT 




012 


FF 




013 • 


CR 


move cursor to beginning of line 


014 


SO 




015 


SI 




016 


DLE 




017 


DC1 


resume sending data 


018 


DC2 




019 


DC3 


stop sending data 


020 


DC 4 




021 


NAK 




022 


sra 




023 


ETB 




024 


CAN 




025 


EM 




026 


SOB 
ESC 




027 


carry out function as defined below 


028 


FS 




029 


GS 




030 


RS 




031 


OS 




127 


DEL 
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FUNCTION WHEN RECEIVED 



<ESC>[Ax 
<ESC>[Bx 
<ESO[Cx 



<ESC>[M 
<ESO[N 
<ESC>[0 

<ESO[P 
<ESC>[Q 
<ESO[R 

<ESC>[S 
<ESC>[T 
<ESC>[CJ 

<ESC>(Y 
<ESC>[Z 
<ESC>[[ 



place the cursor at position x 
insert character x at cursor position 
delete character at cursor and insert 
character x at end of line 
delete character at cursor and insert 
character x at beginning of line 
send user information 



display visible <CR> 
display visible <LF> 

LED1: on (contact with system) 

(green) blinking (no contact with system) 
off (power off) 

LED2: on (external call ind. on) 

(orange) blinking (no function) 

off (external call ind. off) 

LED3: on (Manual radio mode) 
(yellow) blinking (Call indication man. mode) 
off (MOBITEX) 
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3.3.2 Sending data 



The terminal stops when it has received XOFF (DC3) from MCU and 
does not restart until XON (DC1) is received. All characters 
are interpreted as when receiving except for the <ESC> 
sequences defined in the following table: 



SEQUENCE 


FUNCTION WHEN SENDING 


<ESC>OA 


place cursor at beginning of text 


<ESC>OB 


place cursor at end of text 


<ESC>OC 


move cursor one step to the right 


<ESO0D 


move cursor one step to the left 


<ESC>OE 


user information follows (2048 octets) 


<ESC>OHxy 


display size: x=character/line, y=no. of line- 


<ESO0K 


user information missing 


<ESC>OM 


send message 


<ESC>OP 


LINE CONNECTION start 


<ESOQQ 


STATUS 


<ESO0R 


EMERGENCY ■ ™"" - - 


<ESO0W 


TELEX 


<ESC>OX 


DATEX 


<ESC>01 


copy 


<ESC>0ra 


lock 


<ESO0n 


LINE CONNECTION end 


<ESC>Oo 


external call indication on/off { toggle >. 


<ESOOp 


TEXT 


<ESO0q 


increase audio volume' 


<ESO0r 


decrease audio volume 


<ESOOs 


loudspeaker on/off (toggle) 


<ESO0t 


cancel 


<ESO0u 


TELEPHONE 


<ESO0v 


MANUAL RADIO MODE 



When the terminal is sending, the character DEL (decimal 127) 
is interpreted as the terminal wishing to remove the character 
to the left of the cursor. 

Following ASCII codes are used to control MANUAL RADIO mode: 



Q 

w X 


channel number where x=channel number 01 - 99 


E 


squelch on/off (toggle) 


R xxxxxxx 


selective call to xxxxxxx, x = 0 - 9 


T 


transmit call tone 


y 


loudspeaker on/off (toggle) 


u 


scanning 


i 


external call indication on/off (toggle) 
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3.4 PROTOCOL FOR ANSI TERMINAL 
3.4.1 Receiving data 

To stop the data stream from MCU temporarily, the ANSI terminal 
sends XOFF (DC3) and to restart the data stream it sends XON 
(DC1). Received characters in the code range 32 - 126 (decimal) 
ace displayed directly. Other codes are interpreted by the ANSI 
terminal according to the -following tables: 



CHARACTER 


CODE 


ANSI terminal's interpretation of character 


000 


NUL 




001 


SOH 


_ 


002 


STX 




003 


ETX 




004 


EOT 


- 


005 


ENQ 




006 


ACK 




007 


BEL 


give audible signal 


008 


BS 


move cursor one step to the left 


009 


HT 




010 


LF 


line feed 


011 


VT 




" 012 


FF 




013 


CR 


carriage return 


014 


SO 




015 


SI 




016 


OLE 




017 


DC1 


resume sending data 


018 


DC2 




019 


DC3 


stop sending data 


020 


DC 4 




021 


NAK 




022 


SYN 




023 


ETB 




024 


CAN 




025 


EM- 




026 


SUB 




027 


ESC 


carry out function as defined below 


023 


FS 




029 


GS 




030 


RS 




031 


US 
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SEQUENCE 


FUNCTION WHEN RECEIVING 


<ESC>[A 

<£SC>[3 

<ESC>[C 

<ESC>[D 

<ESC>[c 

<ESC>[0q 

<ESC>[lq 

<ESC>[2q 

<ESC>[3q 

<ESC>[4q 


cursor up one step 
cursor down one step 
cursor right one step 
cursor left one step 
restart of terminal from MCD 
switch off LED1 — LED4 (not ANSI) 
switch on LED1 (not ANSI) 
switch on LED2 (not ANSI) 
switch on LED 3 (not ANSI) 
switch on LED 4 (not ANSI) 



For the meaning of LED1 - LED 3 see terminal with small display. 

If additional functions are required, we recommend the use of 
functions and control sequences in accordance with 
ANSI X 3.41 1974. and ANSI X .3.64 19.79-.. 
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3.4.2 



Sending data 



The ANSI terminal stems sending when it has received XOPF (DC3) 
from MCU and does not" restart until XON (DC1) is received. All 
characters are interpreted as when receiving, except for the 
<ESC> sequences defined in the following table: 



SEQUENCE 


FUNCTION WHEN SENDING 


<ESC>OA 


move cursor up one step 


<ESC>OB 


move cursor down one step 


<ESC>OC 


move cursor one step to the right 


<ESC>OD 


move cursor one step to the left 


<ESOOE 


<ESOOF 




<ESC>OG 




<ESC>OHxy 


display size: x=character/line,y=no. of lines 


<ESOOI 




<ESC>OJ 




<ESC>OK 


user information missing 


<ESC>OL 




<ESC>OM 


.send message 


<ESC>ON 




<ESC>00 




<ESC>OP 


LINE CONNECTION Start 


<ESC>OQ 


STATUS 


<ESC>OR 


EMERGENCY 


<ESC>OS 




<ESC>OT 




<ESC>OU 




<ESC>OV 




<ESC>OW 


TELEX {not in ANSI standard) 


<ESC>OX 


DATEX (not in ANSI standard) 


<ESOOY 




<ESC>OZ 




<ESC>0[ 




<ESC>0\ 




<ESC>0] 





{Continued on next page) 
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SEQUENCE 


FUNCTION WHEN SENDING 


<ESC>Oa 




<ESC>0b 




<ESOOc 




<ESOOd 




<ESC>0e 




<ESOOf 


- 


<ESO0g 




<ESC>6h 




<ESC>Oi 




<ESO0j 




<ESOOk 




<ESC>01 


copy 


<ESO0m 


lock 


<ESO0n 


LINE CONNECTION end 


<ESC>Oo 


external call indication on/off (toggle) 


<ESOOp 


MOBITEX, start sending message 


<ESOOq 


increase volume 


^ESOOr 


decrease volume 


<ESO0s 


loudspeaker on/off 


<ESC>0t 


cancel 


<ESC>Ou 


TELEPHONE 


<ESC>0v 


scroll up presentation field 


<ESC>0w 


scroll down presentation field 


<ESC>0x 


get next message 


<ESC>0y 




<ESO0z • 




<ESO0{ 




<ESC>0] 




<ESC>0} 





When the terminal is sending- the character DEL (decimal 127) is 
interpreted as the terminal wishing to remove the character to 
the left of the cursor. 
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3.5 PROTOCOL FOR "MASC" TYPE TERMINALS 

The raasc type interface is designed for connection of units 
with the capacity to handle complete data packets (MPAK see 
reference Rl-09), e.g. a personal computer. Information is 
transferred between the terminal and MCU in the form of frames, 
described in subsequent clauses. Control of the complete mobile 
terminal, e.g. audio equipment and manual mode, is performed by 
special commands included* in the protocol. The interface also 
contains functions for reading status parameters in the mobile 
terminal (meant for the type test). 

For type testing, a raasc type interface is" required. In this 
case it may be implemented by external adaptors. For the type 
testing, only the basic commands and the type testing commands 
are required. 

A frame is formed as a message packet with unique characters 
marking the beginning and the end of the frame. Sending may be 
initiated from both sides. The information frame must be 
acknowledged with ACK before the next information frame -is 
sent. 

The characteristics of the protocol are: ' 

- All characters are coded into the 7 least significant bits 
and bit 8 is used for even parity. 

- The error control is done by longitudinal and character 
parity check and frame length control, 

- Transparent data can be sent in hex coded data fields. 

- The protocol permits full duplex. 

3.5.1 Frame structure 



Communication takes place in the form of frames. There are two 
types of frames, information frames and control frames. The 
information frames are used to transfer commands and other 
information. The control frames are used to control the ■ 
information frame flow. 
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The Information frames are divided into the following fields 
(number of octets stated -below) : 




1 start] length) text jstd.j 


data | check j end j 




1 4 1-2S6 1 


0-1120 2 1 




The Control frames are divided into the following fields 
(number of octets seated below): 




1 start) type) sequ (end | 






110-11 






The maximum frame size permitted is set up by the B-command. 
The maximum possible size is 1150 octets. This means that an 
Information frame can not have the maximum length in all 
fields. _ 




- Start 






The start of a frame is denoted by the character 2. with code 
136/94/5E in octal/decimal/hexadecimal notation. 




All characters received before 
ignored. Every start character 


the start character should be 
is the beginning of a new. frame. 




- Length 






The size of the frame, in number of octets, should be written 
in this field with the ASCII codes of four hexadecimal digits. 
The least significant digit should always be written in octet 
4. 




The size of the frame includes all octets including start and 
end characters. 

Permitted characters of length field: 0-9, A-F. 




- Text 






Text is a field which determines the meaning and the 
interpretation of the frame. The interpretation of the text 
field is carried out by a higher layer. The text field consists 
of at least 1 character and a maximum of 256 characters. 
Numeric information, e.g. command parameters, are always to be 
-given as the ASCII codes of the corresponding hexadecimal 
digits 0-P. 

Permitted characters of text field are: 

SPACE (40/32/20) to } (175/125/7D) except Std(:) and 

startcharacter(") . 
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- Std (start data) 






Text and data are separated by the character : (colon 
72/58/3A). Std should be seated even if the data field is 
empty. 




- Data 






The data field consists of data. 

The coding of the data field is carried out in hexadecimal code 
so that transparent data can be sent. Each octet of data which 
is to be coded into the data field is divided into two half 
octets with four bits- in each. Each of these four bit groups is 
then represented in the data field by the ASCII code of the 
corresponding hexadecimal digit 0-F. Thus each input. octet is 
represented by two characters (octets) in the data field. 




The data field consists of maximum 1120 characters. 
Permitted characters of data field is: 0-9, A-F. 




- Check 






Longitudinal checksum created by exclusive OR on all characters 
starting with the start character and ending with the character 
before the checkfield. The check field consists of two ASCII 
coded hexadecimal digits with the least significant digit in 
octet 2. 




Permitted characters for the check field is: 0-9, A-F 




- Type 






The type of control frame is stated with one character. The 
characters which may be used are * (52/42/2A), ? (77/63/3F), 
! (41/33/21), # (43/35/23) or & (46/38/26). 




- Sequ (sequence number) 






The sequence number for ACK-frames. The sequence number can be 
one of the characters 0 (60/48/30), 1 (61/49/31) or - (minus, 
55/45/2D). 




- End 






The frame is terminated with the carriage return character (CR, 
15/13/OD). A frame which is not ended with the end character 
should be ignored. 


Siprod 
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3.5.2 Information frame 

Messages are sent as Information frames with an expected 
acknowledgement (ACK). 

The text field of an Information frame has che following 
general structure: 



com SP I par 



>=1 0-1 >=0 

com is the command or function code. 

SP is the space character (ASCII code 40/32/20 in 

octal/decimal/hexadecimal notation) which separates the 
command from the parameters. 

par is the ASCII coded parameters or data. 

A command which sets parameter A to 587 can be coded in the 
following ways (all commands are terminated with CR) : 

~0010S A=S87:50 
"0012SET A/587 :D1 

~0010S A:028BAF 028B is hex code for 587 

"000FSA:028B78 SA is a command 



Note: The textfield can only consist of one (1) command. 
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3.5.3 Control frames 

The protocol consist of the following control frames: 



- ACK 

- NACK 

- RACK 



- ACK (Acknowledgement of a correct received frame) 
Structure: 



1*|* ['sequ | CR | 

1111 

ACK means that the received Information frame is correct. A' 
correct frame should comply with the following: 

- starts with the start character {*) 

- contains only one colon ( : ) 

- the fields "check" and "length" have the correct values 

- only permitted characters in text and data fields 

- no characters with parity error 

- the permitted number of characters has not been exceeded in 
any individual field or in the complete frame. 

- ends with the end character (CR) 

The field "sequ" (sequence number) should alter between ASCII 
character 0 and ASCII character 1 for each frame sent, except 
when repeating the latest ACK on a RACK request. Then the same 
value as before is sent again. 

The first time an ACK is sent "sequ" should be the character 0. 
If a RACK is received before any ACK has been sent, the field 
"sequ" will be filled with the character - (minus). "Sequ" with 
the value of - (minus) is only, used when RACK is received 
before ACK has been sent the first time. 



- NftCK (No acknowledgement of an incorrect received frame) 
Structure: 



111 

NACK is to be sent if the conditions for sending ACK are not 
fulfilled and the Information frame: 

- starts with the start character (") 

- contains only one colon ( : ) 

- has a total length of 10 characters or more 

- ends with the end character (CR) 
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Should the criteria not be fulfilled for sending ACK or NACK, 
no reply will be given. The frame will then be repeated by the 
timeout function in the sending unit. 

If the receiving unit cannot handle the incoming data flow, 
NACK may be used to limit the flow. 

- HACK (Request for repetition of the latest sent ACK). 
Structure: 



RACK, request for repetition of the latest sent ACK, is sent 
when no reply on the Information frame has been received within 
10 seconds. The receiver of RACK is to reply by repeating ACK 
with the latest sequence number (sequ) used. 

- SENS (link layer control) ._. ... 

Structure: • . 



SENS is used to control the communication link when there is no 
traffic. The sender decides when SENS will be sent. Time • 
between 2 SENS should be at least 10 seconds. 

When sending a SENS a reply (SACK) will be received within 10 
seconds. If no reply is received within 10 seconds, a hew SENS 
will be sent. When two SENS have been sent and no reply is 
received or no info-frame has been correctly transmitted, the 
communication link is supposed to be broken. A restart will be 
done by sending a B-frame. 

If SACK is received and no SENS has been sent, the SACK will be 
ignored. 

- SACK (Sens acknowledgement) 
Structure: 



SACK will be sent when a controlframe (SENS) has been received. 
It should be sent at the first possible opportunity when 
nothing else is being sent. 
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3.5.4 Flow control and error handling 

If the reply of an Information frame is ACK, the Information 
frame will be correctly .received. The field "sequ" is saved as 
the latest received sequ number. 

If the reply is a MACK , the Information frame will be repeated. 

If there is no reoly within 10 seconds after the Information 
frame was sent, a" BACK will be sent. If there is no reply on 
the HACK, a new HACK will be sent every 10 seconds. If no ACK 
has been received within 30 seconds after the Information frame 
was sent (time-out), higher layers will be notified. However, 
the repetition of RACK will continue until interrupted by 
higher layers or by the fact that an ACK has been received. 

When an ACK is received as a reply to a RACK, the sequ number 
of this ACK will be compared with the stored sequ number of 
latest received ACK. If the numbers are equal, the Information 
frame was not received and must be repeated. If the numbers are. 
different, the Information frame was received correctly (but 
ACK was lost) and the Information frame should not be repeated. 
However, if the sequ number of the. received ACK is - (minus) 
the Information frame must be repeated. 

When the physical layer gets into datatransraission mode the 
link layer is supposed to start up. 

When one of the two interconnected units is started up, it has 
no stored value of the sequ of the latest received ACK. Neither 
does it have a value of the sequ of the latest sent ACK. To 
handle this situation and to prevent a possible doubling of the 
first frame, the following start up procedure is required: 

- The first Information frame sent should be a B-frame. This 
B-frame consists of communication parameters for raasc 
protocol (see appendix A). 

- If the sending of that B-frame leads to error handling with 
RACK, the B-frame must be repeated regardless of the value 
of the sequ field of - the ACK response to RACK. 

The actions to be taken when receiving ACK as a response to 
RACK are summarized in the following table: 

sequ of 









received ACK 










0 


1 




sequ 


none 


repeat 


repeat 


repeat 




of the 






repeat 






latest 


0 


repeat 


no rep. 




received 












ACK 


1 


repeat 


no rep. 


repeat 
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Conaaunication is on a full duplex line. This means that a 
message stream can be in .progress in both directions at the 
same time. Both parties may send an Information frame 
independently of each other and an Information frame may 
therefore be received when a control frame is expected 
(ACK/NACK). However, the next incoming frame will then be a 
reply as each Information frame is to be acknowledged before a 
new one is sent. The minimum time between these two frames will 
be the time set by the ' int {interval) parameter of the 3- 
coramand (minimum time between the sending of two subsequent 
frames ) . 
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3.5.5 Time diagram 








0. MCU/ terminal starts up by setting protocol parameters. 

1. MCU sends Information frame 0 to terminal which sends 
acknowledge • 

.2. MCU sends Information frame 1 which is disturbed and then 
repeated after NACK from terminal. 

3.0 MCU sends Information frame 2 but it does not reach che 
terminal the first time. Information frame repeated after 
HACK and repeated ACK being the same as previous ACK 
(sequ=0). 

3.1 The same as 3.0 but this time ACK[1) dpes not reach the 
sender. RACK is sent and now the repeated ACK, having a new 
sequ, indicates that the frame was received correctly. 

4. MCU and terminal sending Information frames at the same 
time. 

5. MCU and terminal doesn't start at the same time. 
5.5 MCU restarts and B-frame is repeated. 






(Number in brackets after ACK denotes sequence number) 




MCU 


raasc 


protocol 


operator terminal 




0. B(len,int) 








— > 


ACK{0) 








B(len,int) 




ACK(O) 
1. Info frame 0 


















ACK(l) 




.2. Info frame 1 










X > 


NACK 




Info frame 1 






ACK(0) 




3.0 Info frame 2 
timeout 10 s 
RACK 




> 










ACK(0) 




info frame 2 


< 








ACK(l) 












3.1 Info frame 2 

timeout 10 s 
RACK 












ACK(l) 




> 


ACK(l) 
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MCO 



operator terminal 



4. Info frame 3 
time>=int 
ACK(l) 



C 



5. start of MCU 
B<len,int) 
timeout 10 s 
I RACK 



ACK(O) 
^-timeout LQ,-s 
RACK 



5.5 start of MCO 
B(len,int) 

timeout 10 s 
RACK 



Ir.fo frante 4 
ACK(O) 



start of op. ten 
B(len,int) 



ACK(-) 
ACK{0') 
working 
ACK(O) 



ACK{0) 
ACK(l) 
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This interface is intended for the connection of audio 
equipment such as microphone and loudspeaker or a handset. The 
interface also contains certain control functions. 

A simple audio equioment can consist, of a loudspeaker and a 
microphone or a handset with holder and switches so activate 
the functions needed (hook on/off, push-co-caik) . The nandset 
can also be a more comolex uni = using serial data to _ 
communicate over che interface and including a small display 
and numeric and status keys. Some examples, are given in 
application examples. 



4.1 PHYSICAL INTERFACE 

The terminal interface uses a 15-pole DSUB socket (female 
socket with pins) with the following configuration: 



PIN 


SIGNAL 


ACTIVE 


SOURCE 


1 
2 
3 

' 4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 


ground for earphone/loudsp 
data send 
data receive 

extern, call indie, on/off 
volume up 
volume down 

ground for control signals 

system start 

+12V 

-12V 

microphone LP 
microphone ground 
microphone hook on/off 
transmit/receive switch 
earphone/loudspeaker LF 


on = 0V 
up = OV 
down=0V 

start=0V 

lifted=0V 
t.ransm.=0V 


MCU 

audio equipment 
MCU 

audio equipment 
audio equipment 
audio eauipment 
MCU 

audio equipment 

MCU 

MCU 

audio equipment 

audio equipment 
audio equipment 
MCU 



pins: 



Data send/receive 

V24/V28 applies. „ 

Data is formatted in accordance with "terminal with 

small display". 

Exter nal call indication on/off 

When pin 4 is activated, MCU toggles the external 
call indication on/off. When on, the external call 
indicator (e.g. horn) is activated when a message is 
received. 
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pins: 

5,6 Volume up/down . 

Grounding pin 5 or 6 will adjust ths audio level- 
volume) of the loudspeaker or the earphone, 
whichever is active when the pin is activated. (The 
audio level of the inactive unit will remain as 
before.) The adjustment is made in steps, one step 
for each new activation of the pin. If the pin is 
activated continuously, the level to be adjusted by 
one step per second. The lowest level possible to 
set muse still be noticeable. 

8 System start 

MCU will' start up within 10 seconds when pin 8 is 
activated, it then remains on until switched off by 
other means even if the pin is inactivated. 

9,10 Power supply of connected equipment 

+12V (pin 9) is able of supply a current of at least 
500 raA and -12V (pin 10) a current of at least 100 
raA. - 

11,12 Microphone input 

Input impedance: 10 kohm. 

Sensitivity: .An input signal with the frequency 
1 kHz and a level of 100 mV produces an RF deviation 
of 3.0 kHz. This level is produced by the microphone 
at a sound pressure of 94 dB above 2*10 pascal. 

13 Microphone hook on/off 

When the microphone or handset is lifted from its 
holder, pin 13 is activated (HOOK_OFF signal 
generated}. If a handset with earphone is used, the 
loudspeaker will be inactivated and the earphone 
activated. When the microphone or handset is placed 
in its holder again, pin 13 will be inactiveted 
(HOOK_ON signal generated). If an earphone has been 
used, it will be inactivated and the loudspeaker 
activated (for audio level settings, see pin 5,6). 

14 Transmit/receive switch 

When activated, the radio unit will transmit and 
when deactivated, the radio unit will receive (push- 
to-talk switch). 

1,15 Earphone/loudspeaker 

This output is able to support impedances down to 4 
ohms. 

Earphone sensitivity: The earphone produces a sound 
pressure of 85-95 dB above 2*10 pascal when driven 
by a signal with the frequency 1 kHz and a level 
corresponding to an RF deviation of 3.0 kHz. 
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5.1 PHYSICAL INTERFACE 

The terminal interface uses a 15-pole DSDB socket (female 
socket with pins) with the following configuration: 



PIN 


SIGNAL 


ACTIVE 


SOURCE 


1 


emergency 1 


emerg=0V 


emergency 


equip. 


2 


emergency ACK 


ACK =0V. 


MCO 




3 


eraergency_ack. from fixed 


emack=0V 


MCU 




4 

5 


emergency~ack. ACK 


ACK =0V 


emergency 


equip. 


6 


emergency 2 


emerg=0V 


emergency 


equip. 


7 


ground for control signal 








8 


system start 


start=0V 


emergency 


equip. 


9 


+12V (supply) 




MCU 




10 


* 








11 


emergency 3 


emerg=0V 


"emergency 


equip . 


12 


emergency 4 


emerg=0V . 


emergency 


equip. 


13 


emergency LF input 




emergency 


equip. 


14 


emergency LF ground. 




emergency 


equip. 


15 


external indicator 


on = 0V 


MCU 





Emergency 1 

Emergency alarm from an external emergency unit, 
e.g. a receiver for emergencies sent on radio from a 
pocket transmitter. Emergency 1 (pin 1) is used 
together with pin 8 (system start) and pin 2 
(emergency ACK from MCU) to be able to initiate an 
emergency alarm even if MCU is powered off. When the 
external emergency unit' initiates the alarm, it 
activates both pin 1 (emergency 1) and pin 8 (system 
start). After detecting the alarm, MCU sends an 
acknowledge to the emergency unit by activating pin 
2 (emergency ACK from MCU). The emergency unit must 
keep pins 1 and 8 activated until this ACK has been 
received. 

MCU will then create and send a SOS packet to the 
network. 

Emergency ACK from MCU 

Emergency ACK is an acknowledgement from MCU that 
emergency 1 has been received by MCU (response to 
■ activation of pin 1). 
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Emergency acknowledgement from fixed terminal 
When the fixed terminal has received the emergency 
message (SOSINFO), it can send a special emergency 
acknowledge packet (SOSACK) or a request for an 
emergency connection (SOSCONREQ) addressed to the 
alarming" subscription. When a SOSACK is received by 
MCD, it indicates this co the emergency unit by 
grounding pin 3. The emergency unit in turn grounds 
pin 4 as an acknowledgement. 

Additional reactions from MCD when receiving SOSACK 
or SOSCONaSQ are very much depending on application. 
A parameter emergency-acknowledge-status should be 
implemented and stating at least the following: 
status = 0 no additional reaction 

1 activate external indication (e.g. horn) 

2 emergency line connection in direction 
mobile to base (one-way, mobile 
transmitting) 

3 send acknowledge to op. terminal 

Emergency acknowledgement ACK from emergency unit 
Used by the emergency unit to acknowledge the 
activation from MCD of pin 3. 

Emergency 2, 3 and 4 

These pins are intended for initiating an emergency 
alarm from simple emergency equipment such as a 
single push button. When one of these pins is 
activated, MCU creates a SOS packet and sends it to 
the network. Should the pin remain active, the time 
between repeated SOS packets must be at least 1 
minute. The signals are not acknowledged by MCU. 

System start 

MCU will start up within 10 seconds when pin 8 is 
activated. It then' remains on until switched off by 
other means even if the pin is inactivated. 

Power supply for external equipment 

+12V is able to supply a current of at least 500 raA. 

(The emergency unit should always be powered up) 

Emergency LF input- (for emergency connection) 
Input impedance: 10 kohra. 

Sensitivity: An input signal with the frequency 
1 kHz and a level of 100 mV produces an RF deviation 
of 3.0 kHz. This level is produced by the microphone 
at a sound pressure of 94 dB above 2*10 pascal. 

- Activation of external indicator 
This pin is used to activate an external indicator 
(e.g. horn). It is able to sink at least- 100 mA to 
operate e.g. a relay which activates the horn (open 
collector output). 
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6 APPLICATION EXAMPLES 

The interfaces can be used in a variety of ways depending on 
the application. Below are some examples given. 

The terminal equipment can be connected to these interfaces. 

OP. 

terminal interface 
plug 

~ The op. terminal comprises a 

display for- message presen- 
tation and editing and a 
keyboard for entering 
mands and information - 



printer interface 
plug 



25pin 



Printer for printing out 
text or data collection 
unit sending text strings. 



audio interface 
plug 



15pin 



AUDIO EQUIPMENT 

Loudspeaker and microphone 
Or handset with or without 
keys. 

Switches/buttons to control 
interface signals and/or 
serial data according to 
V24/V28. 



emergency interface 
plug 



Emergency unit, e.g. receiver 
for emergencies from pocket 
transmitter, or simple 
emergency buttons to initiate 
emergency signal (SOS) from 
MCO. 
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The following examples are described: 

1. Microphone/loudspeaker 

2. Handset with numeric and function keys 

3. Handset with numeric and function keys, printer 

4. Microphone/loudspeaker, control unit, printer . 

5. Op. terminal with small display, loudspeaker, printer 

6. Op. terminal of ANSI type, microphone/loudspeaker, data 

collection unit 

7. PC, microphone/loudspeaker 

8. PC, handset with keys, printer, emergency equipment 

9. PC, microphone/loudspeaker, control unit, printer, 

emergency equipment 

(PIT = push-to-talk button) 



1. Microphone/loudspeaker 



A*audio interface 



Is able to send/receive speech. (Sends only to default 
receiver) 



2. Handset with numeric and function keys 



3 

■3 



H=earphone 

A=audio interface 
M=microphone 



Is able to" send/receive status and speech. 
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3. Handset with numeric and function keys, printer 



0 § 



H= earphone 

A=audio interface 
M=micro'phone 



- j PRINTER | TP=term. inter f. 

printer 

Is able to send/receive status and speech and to receive text. 
4. Microphone/loudspeaker, "control unit, printer 



IPTT 



LOUDSP 
~ 1 



A=audio interface 



PRINTER TP=term. interf. 
1 printer 



Is able to send/receive status and speech and to receive text. 
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5. Op. terminal with small display, microphone/loudspeaker, 
printer 



A=audio interface 



-j OP-T ERMINAL | TD=term . inter f. 
L — small display 



PRINTER j TP=term. interf. 
printer 



Is able to send/receive text, status and speech. 



6. Op. terminal of ANSI type, microphone/loudspeaker, data 
collection unit. 



MIC "IPTT LOUDSP 



A=audio interface 



j DAT A COLL. | TP=term. interf. 

1 printer 

Is able to send/receive text, data, status and speech. Data can 
be controlled and collected over radio in the form of text 
strings to and from the data collection unit. 
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7. Personal computer as terminal, microphone/loudspeaker 



LOCDSP 



_j 



PC 



A=audio interface 
TM=term. interf. 



Is able to send/receive text, data, status and speech. 

8. Personal computer as terminal, handset with numeric and 
function keys, printer, emergency equipment " 



A=audio interface 



TH=term. interf. 
■masc' 



. PRINTER TP=term. interf. 



TEMERG. EM=emergency interf 



Is able to send/receive text,, data, status, speech and 
emergency. 
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9. Per sonal computer as terminal, microphone/loudspeaker, 
control unit, printer, emergency equipment ~ 



A=audio inter f. 



PRINTER | TP=term. interf. 
printer 



EMERGENCY | EM=emerg. interf r 



Is able to send/receive text, data, status, speech and 
emergency. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4 
Rl-09, 16 



Below are the reference designations listed. 



Reference Section 

Rl-01 .. Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 
Rl-04 ... Terminology 

Rl-05 References """" 

Rl-0£ Network operator information 

Rl-08 Application layer 

Rl-09 ■ Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Ri-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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APPENDIX A, Commands 



This, document specif ies commands in the interface MOBITEX 
ASyncronous Communication (MASC) used between an 
application and a mobile terminal. 
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1 INFORMATION FRAME COMMANDS AND FUNCTIONS IN MOBILE 
TERMINAL 5 

1.1 BASIC FUNCTIONS 5 

1 . 2 TYPE TEST FUNCTIONS . . 6 

1.3 TERMINAL SYSTEM FUNCTIONS ' 7 

1.4 AUDIO FUNCTIONS ' ; 7 

1.5 MANUAL RADIO FUNCTIONS 7 

1.6' USER COMMANDS 7 

2 BASIC FUNCTIONS (always to be implemented in MCU) ... 8 

2.1 B-command (parameters for the MASC protocol) 8 

2.2 M-command (send/receive MPAK via radio) 9 

2.3 E-command (Error command or function) ..10 

2.4 N-command (return of MPAK not sent) 11 

2.5 R-command (return of incorrect MPAK) 12 

2.6 D-command (route received MPAKs to an output) ....13 

2.7 S-command- (sends MPAK to the specified output) ..".15 

2.8 T-command (request/transfer of emergency text). ..16 

2.9 U-command (send emergency signal SOS) 17 

2.10 F P-command (MAN request) , 18 

2.11 F Q-command (device handling the MASC protocol) ..IB 

2.12 F F-coramand (MCU in contact with mobitex) 18 

2.13 F G-coramand (MCU not in contact with mobitex) ....18 

2.14 F H-command (MPAK sent over radio path) 18 

2.15 F K-comraand (error message from MCU) 18 

2.16 F O-command (prepare to close down) .18 

2.17 F #-command (short number list) 18 

3 TYPE TEST FUNCTIONS (always to be implemented in MCU) 19 

3.1 P-command (request/list of parameters) 19 

3.2 PA-comraand (request/list of radio-parameters) ....20 

3.3 PA-command (request/list of identity-parameters) .22 

3.4 PA-command (request/list of channel -parameters ) ..23 

3.5 PA-comraand (request/list of roaming-parameters) ..24 

3.6 PA-command (request/list of test-parameters) 25 

3.7 K-command (receive/transmit frequency number) 27 

3.8 KA-comraand (receive/transmit frequency number) ...28 

4 TERMINAL SYSTEM FUNCTIONS (implemented according to 
application) ....29 

4.1 F B Change to MOBITEX operation mode *.i 29 

•4.2 F C Set up a MOBITEX line connection 29 

4.3 F D Set up a TELEPHONE line connection 29 

4.4 F E Disconnect line connection 29 

4.5 F F Contact with the MOBITEX network 29 

4.6 F G No contact with MOBITEX network : .29 
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4.7 F H MPAK sent by the radio to the network 30 

4.8 F I Cancell previously transmission of; MPAK ....30 

4.9 F J Print out current MANs in terminal 30 

4.10 F K Error message about a fault situation .-. 30 

4.11 F L Activate external call indicacion 30 

4.12 F M Transmitter on/off 30 

4.13 FN Change to MANUAL RADIO mode 30 

4.14 F 0 Prepare for closing down MCO 30 

4.15 • F P Terminal MAN request/answer 31 

4.16 F Q MASC device identity 31 

4.17 F R Change network identification .31 

4.18 F S Change AREA-LIST 31 

4.19 F T. Change TEMP_DEF AOLT_L 1ST 31 

4.20 F V Speech queue information 32 

4.21 F * Short number list 32 

5 AODIO FUNCTIONS (implemented according to 
application) 33 

5.1 A B Increase audio volume level 33 

5*2.-.. A C . ..Decrease audio volume level 33 

5.3 AD Loudspeaker on/off r ....33 

5.4 A E External call indication on/off 33 

'5.5 AH Microphone (hook) on/off 33 

5.6 A T Transmit/receive switch 33 

5.7 A J Hands free 33 

5.8 AV Audio level order 33 

6 MANUAL RADIO MODE FUNCTIONS (implemented according to 
application) "34 

6.1 HA Change to MOBITEX mode 34 

6.2 H 3 Increase audio volume level 34 

6.3 H C Decrease audio volume level 34 

6.4 H D Loudspeaker on/off 34 

6.5 HE External call indication on/off 34 

6.6 H F Call indication 34 

6.7 HG Squelch open/closed (toggle) 34 

6. a H H Microphone (hook) on/off 34 

6.9 HI Transmit/receive switch 34 

6.10 H J Hands free 35 

6.11 H K Change to channel number 35 

6.12 H L Channel number indication 35 

6.13 H M Send selective call number 35 

6.14 H N Scan the specified channels 35 

6.15 HO Carrier indication 35 

6.16 HP Copy of own selective number 35 

6.17 HQ Transmit/receive indicator 35 

7 Signalling between MCO and terminal equipment 
connected to the MASC interface ...37 

7.1 MPAK received from the network 37 

7.2 MPAK received from a terminal 38 

7.3 Connection between the MCU and the terminal 39 

7.4 Signalling between MCO and more than one- terminal 40 
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7.5 Description of a system with MASC interface. ...41 

7.6 Fault situation in mobitex mobile stations .45 

8 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 47 
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1 INFORMATION FRAME COMMANDS 


AND FUNCTIONS IN MOBILE TERMINAL ■ 



The commands, questions arid reolies available as information 
frames in MASC are summarized below and a description is given 
on the following pages. 

1.1 BASIC FUNCTIONS 

The following commands are always to be implemented in MCU. 



3 parameters for the MASC protocol 

M send/receive MPAK via radio 

E error command or function 

N return of MPAK that has not been sent 

R return of incorrect MPAK 

D route received MPAKs to an output 

S send MPAK to the specified output 

T request or transfer of emergency text 

U send emergency signal (SOS-packet) 

F p terminal subscription MAN request and answer 

F Q device handling the MASC protocol 

F F MCU in contact with Mobitex network 

F 6 MCU has no contact with Mobitex network 

F H MCU inform that MPAK has been sent over the radio 

F K Error message from MCU 

F 0 Prepare to close down MCU 

F # Short number list request and answer 
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1.2 TYPE TEST FUNCTIONS 

The following commands are always to be implemented in MCU. 

These functions should only be used during type testing and must 
be made inoperative for normal use. 

All requested parameters which are available in the mobile 
should be included in all answers co type test functions. 

Type test functions consist of commands belonging to specific 
radio protocol. 

To separate mobile terminals with different radio protocol, the 
following commands are available: 

P-coramand Used in mobile terminal at 1200bps. 

K-command Used in mobile terminal at 1200bps. 

PA-coramand Used in mobile terminal at 8/16kbps. 

KA-command Used in mobile terminal at 8/16bps. 
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1.3 TERMINAL SYSTEM FUNCTIONS 

The following commands to be implemented in MCU, according to 
application. 

F system control 



1.4 AUDIO FUNCTIONS 

The following commands to be implemented in MCtJ, according to. 
application. 

A controlling audio functions 



1.5 MANUAL RADIO FUNCTIONS 



The following commands to be implemented in HCU, according to 
application. 



controlling manual radio mode 



1.6 USER COMMANDS 

The following commands are free to use in applications.- 
If used in application, contact mobile raanufactor about 
implementation in MCU. 
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2 BASIC FUNCTIONS (always to be implemented in MCU) 

2 ' 1 B-command (parameters for the MASC protocol) 
Structure of text field: 



1 B }• SP | len j , 1 int | 

11 3 11-4 
The data field is empty. 

The B-command is used to set parameters for the protocol. 

len is a 3-digit ASCII coded hex number which sets the maximum 
length of an Information frame. This field should always be set 
to the maximum possible frame size, i.e. 47E (1150 decimal). 

int is a maximum 4-digit ASCII coded hex number which sets the 
shortest time between two subsequent frames. The value is given 
m 10 ms increments. Default value is int =0. 

len and int are separated by a , ( comma ). 

These parameters should be used as soon as they have been 
received. 

' The default values are used until a B-command has been received. 
A B-command should be the first frame sent after start up. 

After receiving a B-command, the protocol should send a 
start_of_line signal to a higher protocol, to make clear that 
the connection is established and that the start sequence can 
follow. 

Start_of_line signal is an internal signal between the link 
layer and higher layer. 



Exhibit 2, p. 758 



Cantel Mobitex- 



2/1056 - A 296 5175/2 Ue 



1990-02-26 A 



2.2 H-commaad (send/receive MPAK via radio) 
Structure of text field: 



M j SP | ssqu-id 



SP indicate that a sequence number identity is added. If no SP 
then there is no sequ-id. 

sequ-id is a 1-digit ASCII coded decimal number between 0-9. 
This sequence number is an identity of the MPAK. 

Structure of data field: 



[_ ^ _ MPAK ' J 

16-1120 

MOT receiving the M-command sends MPAK via the radio path to the 
network. If M-command consists of a sequence number, the command 
PH indicating 'sent to mobitex network' is sent to terminal 
including the sequence number. Returned MPAK should also 
indicate sequence number. 

MPAK received via the radio path, is sent over the interface to 
the terminal with the M-command (MAN is included in MPAK) . The 
sequence number is not used in this M-command. ' 



The received MPAK ( to be sent via the radio path) should be a 
permitted MPAK concerning valid information in the MPAK head and 
MPAK length (sender, traf state, class, packet type, size of 
MPAK). 

Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.3 E-command (Error command or function) 
Structure of text field: 



The datafield may be used to send information about =he error. 

The E-coramand informs that the previously received command or 
function cannot be executed. (Command or function is noc 
implemented in the receiving unit or included parameters are not 
accepted) . 



A232515M 
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2.4 N-command (return of MPAK not sent) 
Structure of text field: 

1 N ! SP j err-code j , | sequ-id j 

112 11 
SP indicate that an error code and sequence number are added. If 
no SP then there is no error code or sequence number. 

err-code is a 2-digit ASCII coded hex number between 00 - FF. 
This error code is described in chapter "Fault situation in 
raobitex mobile stations". 

vid is a 1-digit ASCII coded decimal number between 0-9. 



sequ- 
This" 



sequence number is an identity of the MPAK. 
Structure of data field: 



L _ _ ! 

16-1120 

The N-command indicates to the terminal that the MPAK has not 
been sent over radio (communication failure or transmission 
interrupted by FO or Fl-command). 

In manual mode MPAK's should be returned by the N-command. 

The MCD can indicate the reason, of not sending the MPAK over 
the radio, by adding the error code. 

If a sequence number is indicated in the M-comraand, then this 
sequence number should also be in the N-frame. 

If no error code or sequence number is valid, this pararameter 
is not added. 

Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.5 fr-command (return of incorrect MPAK) 

When receiving the R-frarae and not finding the fault, the 
receiving unit is supposed to make a restart by sending a B- 
frame. 

Structure of text field: 



j sequ-id i 



SP indicate that an error code and sequence number are added. If 
no SP then there is no error code or sequence number. 

err-code is a 2-digit ASCII coded hex number between 00 - FF. 
This error code is described in chapter "Fault situation in 
mobitex mobile stations". 

-id is a 1-digit ASCII coded decimal number between 0-9. 



This sequence number is an identity of the MPAK. 
Structure of data field: 



16-1120 



MCD uses the R-frame to return an MPAK which was received with 
the M-command and which does not coraoly with the format and the 
rules set by the network and link layers of MOBITEX terminals. 

The MCO can indicate the reason, of not accepting the MPAK, by 
adding the error code. 

If a sequence number is indicated in the M-command, then this 
sequence number should also be in the N-frame. 

If no error code or sequence number is valid, this pararameter 
is not added. 



Description of the different MPAKs can be found in 1 
layer for terminals", see reference Rl-09. 
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2.6 D-command (route received MPAKs to an output) 
Structure of text field: 



I D I SP j MAN I , i 3TG I , j TYP | , } SET | 
1 16 111111 

The data field is empty. 

MAN is a 6-digit ASCII coded hex number stating the MAN for 
which MPAKs are to be routed to output OTG. MAN must be one of 
the possible MANs of the terminal (terminal MAN, group MAN or 
personal MAN] . 

UTG is a 1-digit ASCII-coded hex-number stating the output to 
which received MPAKs are to be routed. 

TYP is a 1-digit ASCII-coded hex-number stating the type of MPAK 
which is to be routed to OTG. _ 

SET is activating the function of set/reset these parameters. 
DTG and TYP to be used as follows: 

OTG = o default output 

1 printer 

2 audio 

3 emergency 

4 op. terminal:! (MASC protocol) 

5 op. terminal: 2 

6 op. terminal: 3 

7 op. terminal: 4 

8 op. terminal :S 

9 op. terminals 

TYP — 0 no types(reset all) 

1 text 

2 data 

3 status 

4 line connection (speech) 

5 emergency ■ 

6 all types except emergency 

7 extpak 

8 hpdata 

9 dteserv 

SET = 0 set these parameters 

1 reset these parameters . 
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After receiving the D-command, MCU will route incoming MPAKs of 
the specified type and intended for the specified MAN to the 
function block which handles the communication (formatting etc) 
for the specified output.. Thus it is possible to route MPAKs to 
several outputs e.g. to both printer and op. terminal. 

When receiving a D-command with UTG="default output", 'the MCU 
resets all earlier D-commands for the SDecified MAN and 
specified TYP. If for example the ?YP is "all types", all 
earlier D-commands concerning this specified MAN are reset and 
all types are sent to default output" connection. If TYP is "no 
types", then all types is reset for this MAN and OTG. 

It is possible to set or reset an earlier D-command, using the 
parameter set or reset. 

After logout, a personal subscription should be removed from 
this list of routing. MPAKs. 

When power on, MCU sets up default outputs, e.g. text, data and 
status.ta op. terminal- and line connection to audio interface. 

All MP AK : DTES ERV is routed to output, where terminal MAN is 
located(can be more than one). 

Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.7 S-command (sends MPAK to the soecified output) 




Structure of text field: 






| S | SP 1 OTG | 






11 1 






Structure of data field: 






[ MPAK 






16-1120 






OTG is a 1-digit ASCII-coded hex-number which states to which 
output MPAK is to be -sent. 


.... 


When receiving the S-command, MCU sends MPAK to the output 

s fcafeed-_fey UTG • ■ • • ■ .. ■ . , T .- ■ • +. 




The parameter OTG is to be used as follows: 




OTG = 0 direct to default output 

1 printer 

2 audio 

3 emergency 

4 op. terminals (MASC protocol) 

5 op. terminal: 2 

6 op. terminal: 3 

7 op. terminal: 4 

8 op. terminal: 5 

9 op. terminal: 6 
A 

B 
C 
0 




E - 

P printer, without printing the MPAK-head 




Nate 1: When the parameter UTG = F, the datafield consists of 

printable information except the MPAK-head. The printer 
should ignore the MPAK-head, this means that the 
information starts in octet 12. 




Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.8 T-command (request/transfer of emergency text). 
Structure of text field, request: 

m 

i 

Structure of data field for transfer of emergency rext: 



Emergency text 
0 - 2S6 



The T-command is used by the terminal to set up in MCD the 
dynamic text part of the emergency signal and as a request to. 
MCD to return the stored emergency text. MCD uses the command as 
a reply to the request. 

The emergency text field is the emergency text which is to be 
transferred. The emergency text can have up to 256 characters 
according to MOBITEX textcode. The first two octets of the text 
part are reserved to indicate the source of the emergency. 

Source of emergency: Emergency 1 - 01 
Emergency 2 = 02 
Emergency 3 = 03 
Emergency 4 =04 
Handset = 05 

OP-terminal 1 = 06 



When receiving a T-command with text part, MCD stores emergency 
text as the dynamic text part of a possible, future SOS packet. 
When receiving the T-command request, the stored emergency text 
is sent to the terminal, by the . T-command with text part. 

Description of the emergency packets and procedures (SOS, 
SOSINFO etc) can be found in "Network layer for terminals", see 
reference Rl-09. 
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2.9 O-command (send emergency signal SOS) 



The O-command is used by the terminal to initiate the 
transmission of an emergency signal (SOS packet). 

When receiving the O-command, MOT creates a SOS packet and sends 
it to the network. The text part of SOS is made up by the stored 
emergency text (received earlier by the T-command) where the 
identity of the emergency source is inserted as the first two 
octets. 

Description of the emergency packets and procedures (SOS, 
SOSINPO etc) can be. found in "Network layer for terminals", see 
reference Rl-09. 

When MOT is in manual mode, it is recommended that the MOT' • 
return to MOBITEX" operating-mode and sends tha packet MPAK:SOS. 
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(MAN request) 



The FP-coramand is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-command. 

2.11 F Q-command (device handling the MASC protocol) 

The FQ-command is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-command. 

2.12 F F-command (MCO in contacc with mobitex) 

The FF-command is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-command. 



(MCU not in contact with mobitex) 
The FG-command is described in chapter TERMINAL SYSTEM FUNCTIONS 



2.14 F B-command- (MPAK sent .over-radio path) 

The FH-command is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-command. 

2.15 F K-command (error message from MCU) 

The FK-comraand is described in chapter TERMINAL SYSTEM FUNCTIONS 



2.16 F o-command (prepare to close down) 

The FO-coramand is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-comraand . 

2.17 F f-command (short number list) 

The F#-command is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-command . 
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3 TYPE TEST FUNCTIONS (always to be implemented in MCU) 

These functions should only be used during type testing and must 
be made inoperative for normal use. 



3.1 P-command (request/list of parameters) 

Structure of text field in request for internal parameters from 
terminal to MCU: 



m 

1 

Structure of text field in reply from MCU to terminal (list of 
parameters ) : 



- |- P I SP |-liSt--of -parameters] 



The data field is empty. 

The F-comraand is used by the terminal to request radio protocol 
parameters and by MCU to send these parameters as a reply to the 
request. 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). The parameters to be sent in the 
following order: 



Parameter 

Slot_length 
Timeout_short 
Timeout_long 
Free_slots 
Rand_slots 
Current_base 
Chosen_slot 
Max_access 
Max_rep 

Priority (internal parameter in MCU) 

Sequential number up (term. MAN) 

Sequential numbers down (term.MAN+15 groups) 

Upfreq (current) 

□ofreq (current) 

Flexlist (MAN 1-7) 

Grouplist (MAN 1-15) 



No of bytes 



(internal parameters in MCU) 
(internal parameters in MCU) 



The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 



A. 393 SUM 
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3.2 PA-command (request/list of radio-parameters) 

Structure of text field in request for internal Darameters £r< 
terminal to MCU: 



Structure of text field in reply from MCU to terminal (list of 
parameters) : 



1 p A01 | SP j^list of_paramaters] 

4 1 >=23 
The data field is empty. 

The PA-command is used by the terminal to- request .radio protocol 
parameters and by MCU to send these parameters as a reply to the 
request. . 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following orders 

Parameter 



Timeout 
Slot length 
Free~slots 
Rand~slots 
Max_rep 
Max~access 
Max~speech 
Txpow 
Slevl 
Slev2 
Scan time 
BadJEase 
Goodjbase 
Choose_base 
Better_base 
Qpos 

Current_base , pommctci. ±u t4 v« > 

Chosen_slot . (internal parameter in MCU) 
Priority (internal parameter in MCU, current value) 
Upfreq (current value) 
Dofreq (current value) 
•Access_channel_upfreq (current value) 
Access~channel dofreq (current value) 
Network id (mobile tx) 
Network~id (mobile rx) 
Area id 



No of bytes 



(internal parameter in MCU) 



Exhibit 2, p. 



CantelMobitex- 



2/1056 - A 296 5175/2 Ue 



1990-02-26 A 



Example of PAOl-comniand: 
MOT 



PA01 01,02,03,04,05.06,07,08,09,10,11,12,13,14,15,16,0017, 
18,19,0020,0021,0022,0023,0024,0025,26 



PA01 01,02,03.04,,,, 



The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Hl-16. 
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(request/list of identity-parameters) 

Structure of text field in request for identity parameters from 
terminal to MOT: 



Structure of text field in reply from MCO to terminal (list of 
parameters ) : 



| SP I list of parameters! 



The data field is empty. 

The -p-command-is- used by the terminal to request radio protocol 
parameters and by MCU to send these parameters as a reply to the 
request. 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following order: 

Parameter No of bvtes 

Terminal MAN 3 

ESN 4 

Flexlist (MAN 0-7) 21 

Grouplist (MAN 1-15) 45 

Sequential number up (term. MAN) i 

Sequential numbers down (term.MAN+15 groups) 16 

Example of PA02-command: 

MCU TERMINAL 



PA01 000001,00000002,000003,000004,000005, , , , ,000010, , , „ 
r, ,,,,,, ,,26,27,, ,,,,,,,,,,,,, 42 

The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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3.4 BA-command (request/list of channel-parameters) 

Structure of text field in request for parameters from terminal 
to MCO: 



Structure of text field in reply from MCtl to terminal (list of 
parameters): 



1 j^list of parameters^] 



4 1 >=4 

The data field is empty. 

The P-command -is -used by -the terminal . to -request radio protocol 
parameters and by MCO to send these parameters as a reply to the 
request. 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following order: 

Parameter Ho of bytes 

Channel_list (current) 1 
Number_of_channels in channel_list (total) 

Number of_channels in this < J 

Channel #1 - upfreq 
Channel #1 - dofreq 
Channel #2 - upfreq 
Channel #2 - dofreq 



Channel-list = Ol(hex) DEFAULT LIST 

02 (hex) " CURRENT LIST 
03(hex) TEMP_DEPAULT_L 1ST 

All parameters in this command is a number of ASCII coded hex 
number . 

Example: Answer with a default list of 100 channels. 

PA03 01, 0064, 3C,0123, 0123, 

PA03 01,0064,28,0123,0123,....,.. 

The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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3 - 5 PA-command (reguest/list of roaming-parameters 1 
to r ilco- re ° f t6Xt fi6ld in request for Parameters from terminal 

1 PA05 | 

4 " 

pirS2t«a)- t6Xt field ln rSply £r ° m MCD " cecminal < lis - ^ 



p&05 I SP Jj-ist of parameter!] 



The data field is empty. 
-■-■^-P-ooBaaaa-is-used by the terminal to request radio -protocol - 
?eq^2st erS y MCtI tD Sfind thSSe P aramet «s as a reply to the 

^ e K list ° f P ara ? eter s consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following order: co 

Parameter No of bvtes 

Number of bases in table i 

Current base id 2 

roaming~value f 

Base_id - £ 

roaming_value 1 



Example: Mobile terminal with current_base(23) choosen. 

PA05 03,0023,09,0025,02,0019,04 

Mobile terminal with no choosen current_base. 

PA05 03,,, 0023,02, 0019, 01 

The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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PA-command (request/list of test-parameters) 



PA06 SP function 



in; 



Structure of text field in reply from MCU to terminal (list of 
parameters): 



| PA06 | SP | function j , | list of_parameters] 

4 1 2 1 >=1 

The data field is empty. 

The. P-command is used by.. the- terminal to request;.. foe. radio, 
protocol parameters and* by MCD to send these parameters as a 
reply to the request. 

The function is a ASCII coded decimal number between 00'- 99, 
describing separate request or answer. Those functions are 
described below. 

The list of .parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following order: 

Function: 

tto£ description: parameter: 

01 current_base(Req/ans) In the answer, the current_base 

is in ASCII coded hex number. 

02 set current_base . Current_base in ASCII coded hex 

number . 

03 disable base searchjnode - 

04 enable base_iearch_raode 

05 clear dynamic memory 

06 enable copy REPMAP when 
receiving or sending the 

frame <REB> An ASCII coded hex number for 

each bit set to "1" indicating 
repetition in the frame <REB>. A 
comma is placed between each 
number. 

07 disable copy REPMAP 

08 enable loudspeaker 

09 disable loudspeaker 
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description; parameter: 

The parameter 'nomret in ASCII 
coded hex number, stating the 
number af retransmissions, 
enable transmitting the 
scrambling signal over 
the radio (see ref Hl-17 ) - 
disable transmitting the 
scrambling signal over 
•the radio(see ref Rl-17 ) - 

copy speech parameters. Subscriber, con-id, upfreq, 
dofreq. Parameters in" ASCII 
coded hex number separated by a 



Example: HOT Terminal 

< PA6 01 

PA6 01 ,1234— — > 

<— ' PA6 02,1234 



PA6 06,6,23,35 



PA6 06 



PA6 13,123456,12,1111,2222 





PA6 


07 




PA6 
PA6 


08 
09 




PA6 


10 




PA6 
PA6 


12 

11 




PA6 


13 



The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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3 « 7 K-command (receive/transmit frequency number) 
Structure of text field to frequency number reception! 



KM | SP I parameter 



Structure of text field to frequency number, transmission: 



The data field is empty in both commands. 

The parameter field-states -the frequency number. The number is 
given as the ASCII codes of the hexadecimal digits of the 
frequency number in hexadecimal notation. 

The K-comraand is used to set up the frequency pair to be used 
for reception and transmission. The frequency number range is 
hexadecimal 001 - 617 (decimal 0001 - 1559). 

If the frequency number included in the frame is not implemented 
in the equipment, MOT will respond with an E-frame (error 
function). 

For correspondence between frequency number and frequency, see 
reference Rl-06 . 
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3.8 KA-command (receive/transmit frequency number) 
Structure of text field to frequency band: 



Structure of text field to frequency number . reception: 



SP | parameter 



Structure of text field to frequency number transmission: 



KAS I SP I parameter 



The data field is empty in all commands. 

The parameter FBI states the frequency band and bitrate. The 
parameter is given as the ASCII coded hex number of the 
parameter FBI in upfreq and dofreq. 

The parameter field states the frequency number. The number is 
given as the ASCII codes, of the hexadecimal digits of the 
frequency number in hexadecimal notation. 

The KA-rcommand is used to set up the frequency pair to be used 
for reception and transmission. The frequency number range is 
hexadecimal 0001 - 1FFF (decimal 0001 - 8191). 

If the frequency number included in the frame is not implemented 
in the equipment, MCU will respond with an E-frame (error 
function) . 

For correspondence between frequency number and frequency, and 
frequency band(FBI) and bitrate , see reference Rl-06. 
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4 TERMINAL SYSTEM FUNCTIONS (implemented according to 
application) 

4.0 F-command (system control) 

The F-command is used from on. terminal to execute the soecified 
function in MOT. 

The F-command is used by MOT to send information to the 
terminal. 

Structure of the text field: 



list of parameters 



The data field is used only in the FT- and F#-frame with list of 
channel numbers and short numbers. 

..The list, of parameters is a . list of one-character function codes 
and parameters in ASCII code according to the following table: 

4.1 F B Change to MOBITEX operation mode 

MOT sends an ACTIVE packet to the network 

4.2 F C Set up a MOBITEX line connection 

parameters MAN1,MAN2 

MAN is a 6-digit ASCII-coded hex-number. 

MANl=sender, MAN2=addressee. 

MOT creates and sends a CONREQ packet to the 

network. 

4.3 F D Set up a TELEPHONE line connection 

Parameters MAN, TEL 

MAN is a 6-digit ASCII-coded hex-number (sender). 
TEL is the desired number in the telephone network. 
The number is given in MOBITEX textcode, right 
justified in a 20 character field with leading 
spaces according to the corresponding field of 
EXTCONREQ. 

MOT creates and sends an EXTCONREQ packet to the 
network. 

4.4 F E Disconnect line connection 

MOT creates and sends a DISCON packet to the 
network. 

4.5 F F Contact with the MOBITEX network 

"MCO is in contact with the MOBITEX network. 

4.6 ' F G No contact with MOBITEX network 

MCO has no contact with the MOBITEX network and is 
trying to establish contact again (roaming procedure 
started). 
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MPAK sent by the radio to the network 
Parameter SEQU-ID 

MCU inform that MPAK has been sent to the network. 
The parameter SEQU-ID is added if SEQU-ID was 
included in the M-comtnand. SEQO-ID is a 1-digit 
ASCII coded decimal number between 0-9. 

Cancell previously transmission of MPAK 
Previously activated transmission of MPAK is 
cancelled. The MPAK =o be returned za the terminal 
by an N-frame. 

Print out current MANs in terminal 

Print current MANs in terminal on printer (terminal 

subscription MAN, group MANs (group list) and 

personal subscription MANs (flex list) in that 

order. 

Error message about a fault situation 
Parameter XX 

- Error message where XX is the error -number in-ASCII 
coded hex digits 00-FF (0-255). . 
Information from MCU about a fault situation. 
Description of the meaning fault situation see 
chapter "Fault situation in mobitex mobile 
stations". 

Activate external call indication 

Activate external indication (e.g. horn) for 2 

seconds . 

Transmitter on/off 
Parameter X 

X = character 0 > transmitter off 

X ■ character 1 > transmitter on 

Change to MANUAL RADIO mode 

MCU sends an INACTIVE packet to the network. 

Prepare for closing down MCD 

From terminal: Command to prepare closing down 

(switching off) the MCD . 

MCU clears buffers for stored MPAKs. MPAKs to be 
transmitted to the network are transmitted. All 
other MPAKs are sent to the terminal. If no contact 
with the network, MPAK's to the network are returned 
by the N-command. 

Then MCU sends an INACTIVE packet to the network. 
Finally MCU confirms that it is empty by sending a 
' FO-frame to the terminal. 
From MCU: MCU is empty and ready to be switched off. 

Note: If more than one device connected, the FO- 
command from the MCU should be sent to all 
devices. 
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4.15 F P Terminal MAN request/answer 

Request from terminal for terminal subscription MAN. 

F PXXXXXX Terminal subscription MAN from MCU to 
terminal as response to the request. 
XXXXXX is the MAN as a 6 digit ASCII coded 
hex number. 

4.16' F Q MASC device identity 
Parameter XXX 

Type of device handling the MASC protocol. 
F_Q(MASC_DEVICE) is information to other units 
connected to this MASC interface. 
XXX = MCO 
XXX = MOX 

4.17 F R Change network identification 

Parameters XXXX.YYYY 

Send this new network identification to data link 
layer(see reference Rl-16). 
- - JCXXX = is new network_ID for mobile tx in ASCII 

coded hex number. 
YYYY = is new network_ID for mobile rx in ASCII 

coded hex number. 

4.18 F S Change AREA-LIST 

Parameters BITMAP.COM 

Send this new area list to data link layer (see 

reference Rl-09 and Rl-16). 

BITMAP = see AREALIST reference Rl-09. 

COM = see Command reference Rl-09. 

Parameters BITMAP and COM is in ASCII coded hex 

digits. 



Change TEMP_DEFAULT_L I ST 
Parameters TNDM,N0M,M 

Send this new channel list to data link layer (see 
reference Rl-09 and Rl-16). 

TNUM = Total number of channels. If TNUM is zero, 
delete TEMP_DEFADLT LIST and return to 
DEFA0I.T_I.IST. ~ 

NUM = Number of channels in this command 

M = 0 No more channels 

M =1 More channels in next command. 

Parameters TNUM, NUM and M is in ASCII coded hex 

digits. 

The list itself is sent in the data field of the 
frame. The list is described in reference Rl-16. 
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4.20 P 7 Speech queue information 

Parameter XX 

Information about queue-position when waiting for 
speech to be connected. 

XX is the speech-queue number in ASCII coded hex 
digits in the range 00-FF. 

4.21 F # Short number lisc 

Request from terminal for short number list. 

F SXX List of short numbers from MCU or terminal. 

The list contains short, numbers which'are 
common to MCU and all connected terminals 
(general short numbers). It is sent by the 
terminal to set up this list and by MCU as a 
reply to the P# request frame from the 
terminal. 

XX is the number of short numbers in the 
list in ASCII coded hex digits in the range 
00-32 (0-50 decimal). 

The list itself -is sent in -the data field -of- - 

the frame. In the list, the actual numbers 
corresponding to each short number from 1 
and up are given as ASCII coded digits with 
a maximum of 20 digits each - . The numbers are 
separated by the character , (comma). 

NOTE: Only the 'one-character function* can be included in an F- 
command, e.g. p P123456. 

Description of the different packets and procedures mentioned 
here can be found in reference Rl-09 and Rl-16. 
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5 AUDIO FUNCTIONS (implemented according to .application) 
5 . 0 A-command (controlling audio functions) - 
Structure of text field: 



I A | SP I list of parameters | 
1 1 >=1 — 

The data field is empty. 

The A-command is used to control the audio equipment. 

The list of parameters is a list of one-character function codes 
and parameters in ASCII code according to the following table: 

5.1 A B Increase audio volume level 

5.2 AC Decrease- audio, volume, level 

5.3 .AD Loudspeaker on/off 

Parameter X 

X « character 0 — > off 
X = character 1 — > on 

5.4 A E External call indication on/off 

Parameter X 

X = character 0 — > off 
X = character 1 — > on 

5.5 AH Microphone (hook) on/off 

Parameter X 

X = character 0 — > off 
X = character 1 — > on 

5.6 A I Transmit/receive switch 

Parameter X 

X = character 0 — > transmit 
X » character 1 — > receive 

5.7 A J Hands free. 

Parameter X 

X = character 0 — > off 
X = character 1 — > on 

5.8 A V Audio level order. 

Parameter X 

X=data, ASCII coded hex digit 0-F. 

NOTE: Only the "one-character function' can be included in an A- 
command, e.g. A EO. 



Exhibit 2, p. 783 



Cantel Mobitex- 



2/1056 - A 296 5175/2 Oe 



1990-02-26 . A 



6 MANUAL RADIO MODE FUNCTIONS (implemented according to 
application) 

6.0 H-conunand (controlling manual radio mode) 

Structure of text field: 



j H I SP I list of parameters [ 
1 1 >=1 
The data field is empty. 

The H-command is used to control the radio equipment when in 
manual radio mode. 

The list of parameters field is a list of one-character function 
codes and parameters in ASCII code according to the following 
table: 

6.1 HA Change to MOB I TEX mode. 

MCU sends an ACTIVE packet to the network. 

6.2 H B Increase audio volume level. 

6.3 EC Decrease audio volume level. 

6.4 H D Loudspeaker on/off. 

Parameter X 

X = character 0 — > off. 
X = character 1 — > on. 

6.5 HE External call indication on/off. 

Parameter X 

X = character 0 — > off. 
X = character 1 — > on. 

6.6 H F Call indication 

Parameter X 

X = character 0 — > no call received 
X = character 1 — > call received 

6.7 E G Squelch open/closed (toggle). 

6.8 EH Microphone (hook) on/off. 

Parameter X 

X = character 0 — > off. 
X = character 1 — > on. 

6.9 HI Transmit/receive switch 

Parameter X 

X = character 0 — > transmit 
X = character 1 — > receive 
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Hands free. 
Parameter X 

X = character 0 — > transmit 
X = character. 1 — > receive 

Change co channel number. 
Parameter XX 

Change zo channel number XX where XX is the desired 
channel number in ASCII coded hex digits in the 
range 01-63 (1-99 decimal). 

Channel number indication. 
Parameter XX 

XX is the channel number in ASCII coded hex digits 
in the range 01-63 (1-99 decimal). Will be sent, whem 
start up or a changed channel occur. 

Send selective, call number. 
Parameter XXXXXXX 

Send selective call number XXXXXXX on current 
...channel. 

X is an ASCII coded digit 0-9. 

If the number of digits is less than 7, the number 
will be left justified and the XXXXXXX-f ield will be 
filled with trailing spaces (hex code 20). 

Scan the specified channels. 
Parameter XX.. XX 

XX.. XX is a list of maximum 8 channel numbers in a 
field of 16 octets. Each XX represents a channel 
number in ASCII coded hex digits in the range 01-63 
(1-99 decimal). If the number of channels is less 
than 8, the field will be filled with trailing 
spaces (hex code 20). 

The specified channels are scanned for' carrier or 
selective call. 

Carrier indication. 
Parameter X 

The frame must be transmitted only when there is a 

change between sensing carrier and sensing no 

carrier. The carrier sense itself should be "updated 

at least once per second. 

X = character 0 — > no carrier 

X = character 1 — > carrier 

Copy of own selective number. 
Parameter XXXXXXX 

Copy of the own selective call number. 
X is an ASCII coded digit 0-9. 

If the number of digits is less than 7, the number 
will be left justified and the XXXXXXX- field will be 
filled with trailing spaces (hex code 20). ' 

Transmit/receive indicator 
Parameter X 
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— > transmitting (sending) 
— > receiving (monitoring) 



Note: Only the 'one-character function' can be included in an 1 
command, e.g. H P1234S67- 
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7 Signalling between HCU and terminal equipment connected to 
the MASC interface. '. 

7 . 0 General 

. These chapters have been included because she network layer may 
be differently implemented in different terminal equipment. For 
any terminal equipment, connected to MCO via the MASC* interface, 
the MCO can be considered as a DCE for connection to the MOB I TEX 
network. A terminal can have a complete MOBITEX network layer or 
a simplified network layer, using different commands of the MASC 
protocol. 

A terminal connected to the MCO must have the same terminal MAN 
number as the MCU. 

The terminal MAN must be associated to at least one output 
connection, either a MASC interface or another connection (e.g. 
a handset or a printer). 

All messages to groups, belonging to terminal MAN, should be' 
directed to the same output connection(s) as terminal MAN. 

The MCU has the responsibility towards the MOBITEX network 
according to the network . layer . 

In order to get the MOBITEX network layer in MCO and the 
terminal to interact correctly, the following chapters have to 
be considered. 



7.1 MPAK received from the network 

ROAMORD , FLEXREQ , INFOREQ and ESNREQ will be completely handled 
within the MCO without notifying any connected terminal. 

DIE and LIVE will be completely handled within the MCU but 
notified by FK-comraand(if handled) to connected terminals. 

All other correctly received MPAKs will, after normal handling 
in the MCO, be sent to the output connection where the addressed 
MAN is located. 

A fixed terminal can't receive a CONORD, therefore CONORD is to 
be converted to a CONREQ by the MCO. 
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7.2 MPAK received from a terminal 

Normally, if the MPAK passes the checks in the MCU, the MPAK 
will be sent to the network. The MCU should react and enter 
states as if the MPAK was generaced in che MCU (e.g. on CONREQ 
the MCU should enter a scace for call in progress, and should 
axso act according to the radio protocol for sending such MPAK) . 

If the checks fail, the MPAK should he returned to the rermina- 
by an R-frame. 

For the following MPAK's, however, the MCU should have a sDecial 
treatment. 

CONREA to be treated as a hook off -signal 

DISCON .. to be treated as a hook on-signal 



FLEXREQ 



if the personal subscription already 
exist "±n-flexlist the terminal will be 
informed by FK-frame. 



FLEXLIST 



to be returned to the terminal by an R- 
frame. 



BORN, 
ROAM, 
INFO, 



ESNINFO 



to be returned to the terminal by an R~ 



f rame. 



LI NEON, 
LINEOFF 



to be returned to the terminal by an R- 



frame. 



A2S2 51M/3 
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7.3 Connection between the MCO and the terminal 

The terminal is supposed to have a list of groupMAN's and a list 
of personal subscriotions (fiexlist). In order to get the lists 
in the MCO equivalent to the list in the terminal, the following 
should be considered. 

Each time the link layer connection is established (by exchange 
of B-frames), the terminal will send: 

- MANREQ (command F ?) to request MCO for the terminal MAN 

To answer this, the MCO sends the terminal MAN in the command 
MAN (command F P). This answer should be sent immediately or, if 
another frame is currently being transmitted by the MCO, 
immediately after the transmission is completed. After that, 
the MCO will send the MASC_DEVICE command (F Q). 

The MCO should send: 

__. - GROOPLIST— ■ . to- set the list of groupMAN in. the 
terminal 

- FLEXLIST to set the fiexlist in the terminal. 

The terminal will then handle the fiexlist according to the 
specification, see Rl-09. 
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Example of start sequence when MCU starts. 




MCU 


TERMINAL 




B-frame — > 

MAN-frame > 

MASC DEVICE- frame > 


MANREQ- frame 




GROUPLIST > 






Example of start sequence when TERMINAL starts: 




MCU 


TERMINAL 




MAN-frame ' > 

MASC DEVICE-f rame > 


-S- frame 
MANREQ- frame 




GROUPLIST > 

• FLEXLIST > 






Note: Packets above the dotted line in each sequence 
belong to the link layer, and packets below the 
dotted line belong to the network layer. 




7.4 Signalling between MCU and more than one terminal 




The MCU may have more than one MASC interface. 




All MASC interfaces should have the same start sequence as 
described in chapter "Connection between the MCU and the 
terminal" . 




The MCU handles all MPAKs and messages to different output 
connections where the MAN is located. 
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7.5 Description of a system with MASC interface. 
7.5.1 MCO connected to one terminal. 



MCU handles the terminal MAN, group MAN and' personal MAN with 
GROOPLIST and FLEXLIST in the start sequence. 

After the start sequence, all MPAKs are routed to the terminal. 
7.5.2 MCU connected to two terminals. 













MASC2 . 


TERMINAL2 




MCO 






MASC1 




MASC3 1 




TERMINALl 


—jUNITl 






MASC 4 | 








= — (UNIT2 



MCD handles the terminal MAN, group MAN and personal MAN with 
GROOPLIST and FLEXLIST in the start sequence. 

All terminals that have other terminal equipment connected, will 
have the same start sequence as described in chapter "Connection 
between the MCO and the terminal". These terminals should be 
considered as an MCO by the connected units. 

After the start up sequence ali MPAKs are routed to the current 
terminal . 
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Examples of start sequences. 




EXAMPLE 1. 




Lists, when MAN are correct and MCU starts. 


TERMINAL2 MCU 


TEHMINALl UNITI CSIT2 


S-frame > 





MASC_DEVICE — — 
< B-frame 
MANREQ — > 

< MAN 

< MASC_DEVICE-frame 



< ~GROCJPLIST 

GROUPLIST > 

< FLEXLIST 

FLEXLIST > 

GROUPLIST > 

GROUPLIST 

FLEXLIST > 

FLEXLIST ~ 



Note; Packets above the dotted line in the sequence belong 

to the link layer, and packets below the dotted line 
belong to the network layer. 



a aw sum 
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MAN1 is only in ONIT1 and TERMINALl. MAN2 is only in' MCU. 
MAN1 and MAN2 are personal siibsciptions not included in MCO': 
flexlist. 

TERMINAL2 MCU TERMINALl UNIT1 UNIT 2 

B- frame > 

< MANREQ 

MAN > 

MASC_DEVICE > 

< B- frame 



■ GROCPLIST 
GROOPLIST 

■ FLEXLIST 
FLEXLIST 



Note 2: 
Note 3: 



The terminal/unitl/unit2 will replace former lists with 
these new lists. When replacing the flexlist the 
terminal/unitl/unit2 will decide if MAN1 and MAN2 are 
connected or disconnected. If connected, a loginreq is 
sent from MAN1 in unitl and a loginreq sent from MAN2 
in unit2. If not connected an presentation of the 
logout is sent to the user. 

The application in ONIT1 has to send LOGINREQ for MAN1 
if it wishes to keep MAN1. 

Packets above the dotted line in the sequence belong to 
■the link layer, and packets below the dotted line 
belong to the network layer. 



MCO 



TERMINALl 



DNIT1 0NIT2 



-LOGINREQ 
for MANI 




AS9ZSIS3/J 
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EXAMPLE 3. 

TEHMINAL1 is starting the. connection. 

TERMINALS MCO TERM! MALI DNIT1 0NIT2 

< B-frame 

< MANREQ 

MAN > 

MASC_DEVICE > . 

B-frame > 

< MANREQ 

MAN > 

MASC_DEVICE— > 

B-frame > 

< i MANREQ 



MASC_DEVICE- 



" GROUPLIST 
GROOPLIST 

• FLEXLIST 
FLEXLIST 



Packets above the dotted line in the sequence belong to 
the link layer, and packets below the dotted line belong 
to the network layer. 



A.SS2J1SM 
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7.5 Fault 


situation in mobitex mobile stations. 


This is a recommendation of error message from* the MCU to the 
connected unit using a MASC interface. This error message is a 
response for a fault situation and sent as an error number in 
. the FK-command(see chapter "Information frame commands and 
functions"). 


Error numbers 0 - 4F is reserved for specific meaning. Error 
numbers 50 - FF is free to use. 


New meaning 


of error numbers is 


described in Rl-06. 


Error no: 


meaning: 




0 


reserved 




1 


DIE mode. 


An MPAK-.DIE is received. No user 
traffic can be sent from the 


2 


LIVE mode. 


An MPAK:L.IVE is received. . Dser 
traffic can be sent from the 
MCU. 


3 


SPEECH mode. 


The MCU is in speech mode and 
can not send any traffic except 
MPAK:CSUBCOM. 


4 


MANUAL mode. 


The MCU is in the manual mode 
and not in contact with mobitex 
network. . 


5 


reserved 




•6 


reserved 




7 


reserved 




8 


reserved 




9 


reserved 




A 


Receiver buffer full, waiting for free buffer. 


B 


Buffer/memory free. 




C 


No memory, waiting for more memory. 


D 


reserved 




E 


reserved 




F 


reserved 
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Error no; 


meaning. 




Returned MPAK during die mode. 




Returned MPAK during speech mode. 




Returned MPAK during manual mode. 




Returned MPAK during buffer full. 




reserved 




reserved 




Loginrequest MAN already exist in 


17 


Loginrequest MAN is not possible, 


* 8 


MPAK sender MAN is not in TMAN or 


19 


reserved 


1A 


reserved 


IB 


reserved 


1C 


reserved 


ID 


reserved 


IE 


reserved 


IF 


reserved 


20 - 4F 


reserved 
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8 HOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 27, 28, 45 

Hl-09, 9, 11, 12, 14, 15, 16, 17, 31, 32, 39 
Rl-16, 19, 21, 22, 23, 24, 26, 31, 32 
Rl-17, 26 



Below are the reference designations listed. 
Reference - Section 



Rl-01 
Rl-02 
Rl-03 
Rl-04 
Rl-05 
Rl-06 
Rl-08 
Rl-09 
Rl-11 
Rl-12 
Rl-16 
Rl-17 
Rl-18 
Rl-19 
Rl-20 



Arrangement of the documents 
-44QBITEX System description 
General description of terminals 
Terminology 
References 

Network operator information 
Application layer 
Network layer 

Interface requirements, fixed terminals 
Other requirements, fixed terminals 
Link layer, mobile terminals 
Physical layer, mobile terminals 
Radio equipment, mobile terminals 
Other interfaces, mobile terminals 
Other requirements, mobile terminals 
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APPLICATION EXAMPLE 
OF HOW TO MAKE AN ALTERNATE CONNECTION VIA MCU 
FOR FIXED TERMINALS WITH MASC INTERFACE. 
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1 INTRODUCTION 

This document describes an example (i.e. not a 
specification) of an- MCO application. Its Durpose is to 
aake it easier for zhe manufacturers. ?or Vne 
understanding of chis documanc, zhe reader has to be well 
informed about the Networx layer for terminals { reference 
Rl-09 ) and Link layer for mobile terminals { reference 



A fixed terminal may be directly connected to the MOBITEX 
network via a masc interface (MASC) see document "Other 
interfaces" and appendix A "Commands". The aoplication in 
this document describes how sucn a terminal may be 
connected via an MCtI, that handles the masc interface. As 
to the requirements of such a terminal, Dlease refer to 
chapter 7 in this document. 
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2 MCO WITH APPLICATION 

Figure 1 shows an MCU with its processes. Each orocess 
communicates with the other processes as is indicated by 
the arrows in the figure. 



AUDIO HANDLER 

"AUDIO" 



APPLICATION 
DIRECTOR 

"APP DIR" 



MASC HANDLER 1 
"MASC1" 



MASC HANDLER ! 

"MASCn" 



NETWORK LAYER 
"RADIO NET" 



In the centre of figure 1 is a process called APP_DIR, 
application director. This document will describe that 
process. 



The audio handler (AODIO) handles an audio interface. 

The printer handler (PRINTER) handles a printer, connected 
to the MCU. 

Furthermore one may have "emergency handler", "terminal 
with small display handler" etc. 

The network layer (RADIO_NET) is a normal MOB I TEX network 
layer for mobile terminal, plus the additions made in 
chapter 7 (Requirements on network layer in MCU in this 
application). 
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The letters A, B and C represent different signalling 
sequencies. Observe that the HASC handler and the r>r inter 
handler acts similarly towards the application director. 
All handlers act in the same way as an MASC handler 
towards the application director. 



Following terms are used in this document: 

- line handler common name for all handlers. E.g. 

HASC1 , MASC7 , AUDIO ... 

- MCO_MAN the mobile terminal's MOBITEX 

subscription number. 
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3 DESCRIPTION OF SIGNALS 

All signals that are handled by APPJJIR have che following 
structure: 



origin 



signal_status 



Original sender. Can be: line handler, 
RADIOJJET or 
APP DIR. 



Sender. Can be : 



line handler, 
RADIOJIET or 
APP .DIR. 



Signal status can be signal_status_olc or 
signal_status_not sent. 
Signal status is always set to 
signal_status_ok when the signal is 
created. 

If the RADIO_NET or any of the line 
' handlers fails to transmit a signal, 
signal status will be set to 
signal_status-_not_sent. Then the signal 
is returned to APP_DIR. 

Can be: S hook on, 
S_hook~off , 
S_MPAK, 

S~MPAK_sent_on_radio , 
S_returned_incor rect_MPAK , 
S_not_sent_MPAK 
S_line_up,~ 
S_line_down. 

If signal_type isS_MPAK, S_not_sent_MPAK 
or S_returned incorrect_MPAK, it contains 
an HPAK in this field. 



A ±U 515313 
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Description of the signal types; 
. S line up 

S_line_up is sent fay all line handlers to APP_DIR after a 
correct start or restart. 

If the line handler is an MASC_handler , the starting up 
■ sequence will send a PRIM_MASC~f rame and an 
acknowledgement of this will be received from the 
connected unit before S_line_up may be sent. 

If the line handler is a PRINTER , it is recommended that 
S_line_up is not sent until the modem signals say there is 
a printer connected. 



S line down 

S line down is sent by all line handlers to APP_DIR when 
tEe unit is disconnected. 

"if the line handier fails to transmit a signal to the 
connected unit, S_line_down will be sent to APP_DIR 
together with the~signal being returned. ~ 



S_HPAK is the normal signal being sent between line 
handler and AFP_DIR and between RADIO_NET and APP_DIR. In 
the normal case, signal status is signal_status_ok. But in 
the case when line handler or RADIOJJET fails to transmit 
the signal, signal status will be set to 

signal_status not_sent and the signal will be returned to 
APP_DIR, For Further information see examples below 
{chapter 4) . 

When an S MPAK is received by the MASC-handler, the MASC- 
handler must send an M-frame to the connected unit 
according to the raasc protocol. 

When an M-frame is transmitted from the connected unit , to 
the MASC-handler, the MASC-handler must send an S_MPAK to 
APP DIR. 



S returned incorrect MPAK. 

S_returned_incorrect_MPAK is sent by APP DIR to line 
handler if an incorrect MPAK was received".. . 

If an-MASC handler receives a s_returned_incorrect_MPAK, . 
this MPAK will be sent to the connected unit in an R-frame 
according to the masc protocol. 
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S not sent MPAK. 

S_not_sent_MPAK is sent by APP DIR to line handler if, for 
some reason, it is impossible to transmict a mnaic on 
radio. 

If an MASC handler receives a S not sent MPAK, this MPAK 
will be sent to the connected unit in an N-frame accordinq 
to the masc protocol. 

S MPAK sent on radio 

s_MPAK_sent_on_radio is sent by RADIO NET to APP oir when 
an MPAK has been sent via radio. Origin helps APP dir - 0 
direct this signal to correct line-handler. When the MASC 
handler receives an S_MPAK_sent_on_radio, it uses the masc 
F _ H ~«ame to send the signal to connected unit. 

S hook off 

S_hook_off is sent by AUDIO to APP DIR at hook off. 
APP_DIR updates its registers and passes the signal on to 
RADIO_NE.T. 

An MPAK CONREA, received by APP DIR' from connected unit, 
will not be sent to RADIO_NET. Instead S hook off will be 
sent from APP_DIR to RADIO NET. ~ ~ 

S hook on 

S hook_on is sent by AUDIO to APP_DIR at hook on. APP DIR 
updates its registers and passes the signal on to 
RADI0_NET. 

An MPAK DISCON, received by APP_DIR from connected unit, 
will not be sent to RADIO NET. Instead S hook on will be 
sent from APP DIR to RADIO NET. 
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4 EXAMPLES OF SIGNALLING IN THIS APPLICATION 

4.1 EXAMPLE 1: sending TEXT successfully 

Unit A sends an MPAK TEXT to a subscriber 3 in the MOBITEX 
network. Transmission via radio is successful. 



TERMINAL A 



protocol 



signal signal_type 



origin 



from 



signal_status 



1 raasc frame M 

2 S_MPAK MASCn MASCn 

3 S_MPAK MASCn APP_DIR 
4-6 are not handled in this document. 

7 S_MPAK_sent_on_radio MASCn RADIO_NET signal_status_ok 



signal_status_ok 
signal_status_ok 



S_MPAK_sent_on_radio MASCn 
masc frame F H 



APP_dir signal_status_ok 



Observe that origin = MASCn through the whole sequence. 
This gives APP_DIR an opportunity to route signals easier 
back to the sender. 



Exhibit 2, p. 806 



Cantel Mobitex- 



1/10S6 -.A 296 5175 Oe 



4.2 EXAMPLE 2: sending TEXT unsuccessfully 

Onit A sends an MPAK TEXT to a subscriber B in the MOB I TEX 
network. APPJ3IR discovers some kind of error. 



TERMINAL A 


MCU 








MASCn 


2 


APP DIR 




4 • 

MASC 
protocol 






3 


RADIO_NET 
ROSI 



signal signal_type origin from signal_status 

1 masc frame M 

2 S_MPAK MASCn MASCn signal_status ok 

3 S_returned- 

I _incorrect_MPAK MASCn APP_DIR signal_st:atus ok 

4 masc frame R 

Observe that signal 3 has signal status set to 
signal_status_ok. Only line handlers and RADtO_NET may set 
signal status to signal_status_not sent. 



A-.Q2SI513 
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4.3 EXAMPLE 3: sending TEXT unsuccessfully 

Onit A sends an MPAK TEXT to a subscriber 3 in the MOBITEX 
network. Transmission via radio fails. 



TERMINAL A 

■ 


MCU 


i 

> 

MASCn 

< 


APP DIR 


9 

HASC 
— ... protocol - 


1 a 


7 | |,. 


RADIO NET 




«l I 4 ■ 




ROSI " 



15 

FAIL . 



signal signal_type 



origin 



from 



signal_status 



signal_status_ok 
signal_status_ok 



1 raasc frame M 

2 S MPAK MASCn MASCn 

3 S MPAK MASCn APP_DIR 
4-6 are not handled in this document. 

7 S_MPAK MASCn RADI0_NET signal_status- 

~ not_sent 

8 S_not_sent_MPAK MASCn APP_DIR signal_status_ok 

9 masc frame N 
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4.4 EXAMPLE 4: sending TEXT unsuccessfully. 

Unit A sends an MPAK TEXT eo a subscriber B in the MOBITEX 
network. Transmission wia radio fails. The MCO fails =o 
return the packet co unit A. 



Q 



FAIL< — 
9 



HASC 
protocol 



FAIL 



signal signaltype origin from signal_status 

1 masc frame M 

2 S_MPAK MASCn MASCn signal status ok 

3 S_MPAK MASCn APP_DIR signal~status~ok 
4-6 are not handled in this document. 

7 S_MPAK MASCn RADIO JJET signal_statqs- 

not sent 

8 S_not_sent_MPAK MASCn APP_DIR signal status ok 

9 masc frame N ~ ~ ~~ 

10 S_not_sent_MPAK . MASCn MASCn signal_scatus- 

_not_sent 

This sequence is the same as the one in example 3, except 
for signal 10. When receiving signal 10, APPJ3IR discovers 
that origin = from, i.e. the signal is returned even from 
t.he MASC handler. The only thing APP DIP. can do is to 
forget the signal. 
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4.5 EXAMPLE 5: receiving TEXT successfully 
MCU receives an MPAK TEXT, addressed to MCU-MAN. 



Q 



MASC 
protocol 



signal signal_type origin from signal_status 

1-2 are not handled in this document. 

3 S_MPAK RADIOJJET RADIOJJET signal status ok 

4 S_HPAK RADIO_NET APP_DIR signal status_ok 

5 • masc frame M 



The sequence above is valid if there is only one line 
handler. 

If an MPAK is addressed to the MCU_MAN , and there is more 
than one line handler, APP DIR. will send a copy of signal 
4 to each one of them. But~if the MPAK is addressed to a 
transferred MAN, APP_DIR will know on which of the line 
handlers this MAN can be reached. 
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4.6 . EXAMPLE 6: receiving TEXT unsuccessfully 

MCD receives an MPAK TEXT to unit 3. Transmission to unit 
B fails. There is only one recevier in this example and 
MPAK is addressed to MCO MAN. 



MASC 
protocol 



signal signal_type 



origin 



signal_status 



■ 2 are not handled in this document. 



S_MPAK 
S_MPAK 
masc frame M 
S MPAK 



RADIO_NET RADI0_NET signai_status_ok 
RADIO_NET APP_DIR signal_status_ok 



RADIO NET MASCn 



Observe that an MPAK, addressed to MCU_MAN or any MAN 
included in the grouplist, must not under any 
circumstances, be returned to the MOBITEX network. In this 
application, APP DIR forgets the MPAK. 
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4.7 EXAMPLE 7: receiving CONREQ 

MCD receives an MPAK CONREQ addressed to unit B. Unit 3 
responds with an MPAK CONREA after which the call can 
begin. Dnit B terminates the call by sending an MPAK 
DISCON. 



|3 |b T 



2 9 1 14 



signal signal_type 



origin from signal_status 



RADIO NET signal status_ok 
app_dir signaljstatus_ok 



signal_status ok 
signal_status~ok 



1-2 are not handled in this document 

3 S_MPAK RADIO_NEX 

4 S_MPAK RADIO_NET 

5 raasc frame M 

6 masc frame M 

7 SJ4PAK HASCn HASCn 

8 SJiook off MASCn APP_DIR 
9-10 are not handled in this document. 

11 masc frame H 

12 S_MPAK HASCn MASCn 

13 S_hook_on MASCn APP_DIR 

14 - 15 are not handled in this document 

Note: signal 1-5 contains MPAK CONREQ. 

signal 6-7, 9-10 contains MPAK CONREA 
signal 11-12, 14-15 contains MPAK DISCON 

. In this application S_hook_on and S_hook_off are always 
sent, instead of MPAK DISCON and MPAK CONREA, to the 
RADIO NET. 



signal_status_ok 
signal_status_ok 
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4.8 EXAMPLE 8: receiving CONREQ 

MCO receives an MPAK CONREQ addressed to unit B. The audio 
interface generates a hook off after which the call can 
begin. The call is" terminated by the audio interface 
generating an hook on. 



protocol 



3 17 111. 



2 8 12 



signal signal_type 



origin 



signal_status 



RADIO_NET signal_status_ok 
APP_DIR signal_status_ok 



AUDIO 
APP DIR 



• 2 are not handled in this document 
S_MPAK RADIOJJET 
S_MPAK RADIOJJET 

masc frame M 

S hook off AUDIO 
S~hook~off AUDIO 

9 are not~handled in this document. 



S_hook_on AUDIO AUDIO 

S_hook_on AUDIO APP_DIR 

• 13 are not handled in this document 

S MPAK RADIO_NET APP_DIR 

masc frame M 

: signal 1-5 contains MPAK CONREQ 
signal 8-9 contains MPAK CONREA 
signal 12 - 15 contains MPAK DISCON 



Observe that APP_DIR generates MPAK DISCON to unit B 
This is to avoid blocking situations in unit B. 



signal_status_ok 
signal_status_ok 



signal_status_ok 
signai_status~ok 



signal_status_ok 
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5 LISTS OF SIGNALS 




Signals that are sent within the MCU, interfaces A, B and 
C in figure L, are iisted below. The signals are divided 
into categories of' normal and returned signals. 


5,1 Interface A 




5.1.1 Signals sent from APP_DIR to line handlers 


Normal signals 




SJ4PAK 

origin = 
from = 
signal_status = 
signal type = 
MPAK 


creator of this signal 
APP DIR 

signal status ok , 
S MPAK 

MPAK in question 


S_not_sent_MPAK 

origin = 
from = 
signal status = 
signal type 
MPAK 


creator of original MPAK 
APPJDIR 

signal status ok 
S_not-sent_MPAK 
MPAK Tn question 


S returned incorrect MPAK 

origin = 

signal_status = 
signal type = 
MPAK 


creator of original MPAK 
APP DIR 

signal status_ok 

S returned incorrect MPAK 

MPAK in question ~ 


S_MPAK_sent_on_radio 

origin ~ - 
from = 
signal status = 
signal type = 


creator of original MPAK 
APP_DIR 

signal_status_ok 
S_MPAK_sent_on_radio 
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5.1.2 Signals sent from line handlers to APP_DIR 




Normal siqnals 








S 1 i ne_jup 

origin 

signal_status 
signal_type 


= 


line handler in question 
origin 

signal_status ok 
S_line_up 




S_line_down 
origin 
from 

s ignal_status 
signal~type 




line handler in question 
origin 

s i g na l_s t a tus_o k 
S_line~down ~ 




S_MPAK 

origin ■• 
from 

signal status 

signal~type 

MPAK 




line handler in. question 
origin 

signal status ok 
S MPAK" 

MPAK in question 




Returned siqnals 








S_MPAK 

origin 
from 

signal_status 
signal type 
MPAK 




no change in this field 
line handler in question 
signal status not sent 
S MPAK ~ ~ 
MPAK in question 




S_MPAK_sent on radio 
origin ~ 
from 

signal status 
signal~nype 




no change in this field 
line handler in question 
signal status not sent 
S_MPAK_s e n t_o n_r aai o 




S_returned incorrect MPAK. 
origin = 
from = 
signal status = 
signal~type = 
MPAK 


no change in this field 
line handler in question 
signal_status not sent * 
S_returned_incorrect_MPAK 
MPAK in question 


3;U.i.r. 


S_not_sent MPAK 
origin 
from 

signal status 
signal type 
MPAK 




no change in this field 
line handler in question 
signal status not sent 
5_not_sent_MPAK ~ 
MPAK in question 
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5.1.3 Signals from APPJJIR to AUDIO 


All signals listed in 5.1.1. 




5.1.4 Signals from AUDIO 


to APP_DIR 


All signals listed in 5.1.2, 


plus the following: 


S_hook_off 

origin 
from 

signal_status 
signal~type 


ii ii ii n 




AUDIO 
AODIO 

signal status ok 
S_hook_off ~ 


S_hook_on 

origin 
from 

signal status 
signal type 






AODIO 
ADD 10 

signal status ok 
S_hook_on ~ 


5.1.5 Signals from APPJ3IR to RADIO_NET 


Normal siqnals 








S_HPAK 

origin 
from 

signal status 
signal type 
MPAK ~ 


M II II II II 




creator of this signal 
APP_DIR 

signal status ok 
S_MPAK 

MPAK in question 


S_hook on 

origin 
from 

signal status 
signal_type 






AODIO 
APP DIR 

signal_status ok 
S_hook_on ~ 


S_hook_off 

origin 
from 

signal status 
signal type 






AODIO 
APP DIR 

signal_status ok 
S_hook~off 
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S.1.6 Signals from RADIOJ3ET to APP_DIR . 


Normal signals 






S_MPAK 






origin 




RADIOJIET 


from 


= 


origin . 


signal_status 


= 


signal status ok 


signal type 




S MPAK 


MPAK 


'" 


MPAK in question 


Returned siqnals 






S_KPAK 






origin • 




no change in this field 


from 




RADIOJIET 


signal_status 




signal status not sent 


signal*~type 




S_MPAK~ 


MPAK 




MPAK in question 


S_hook_on 






origin 




AUDIO 


from 




RADIOJJET 


signal_status 




signal_status not sent 


signal_type 




S_hook~on 


S_hook off 






origin 




AUDIO 


from 




RADIO NET 


signal status 




signal status hot sent 


signal~type 




S hook off 
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6 REGISTERS IN APP_DIR 

Four registers are kept in APPJ3IR: 

6.1 Register number one: MCOJREG 

The register called MCD_REG has the structure shown in the 
figure below. 



LINE 


MASC1 MASC2 MASC3 ADDIO PRINTER 


MAY / MAY NOT 
INACTIVATE MCO 




LINE OP / 
LINE DOWN 






TEXT 






STATUS 




MSG 
TYPE 


DATA 




HP DATA 






SPEECH 






EMERGENCY 











line 

Contains the line handlers that exist in this 
application. This is static information. 

msg type 

Tells which MPAKs, addressed to MCU_MAN or any MAN in the 
grouplist, will be received by the Tine handler. As an 
example, there is nothing to prevent that MPAK- TEXT is 
received by a number of line handlers. In the speech 
connection case, in this particular application, only 
one line handler can be enabled. Msg type contains static 
information. 

may/may not inactivate MCO 

Tells whether the line handler in question is allowed to 
inactivate MCO with an MPAK DTESERV . INACTIVE . Normally,, 
only one (or very few) of the line handlers should be 
allowed to do this. This is static information. 
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line up/down 

Contains information about each of the connected line 
handlers. This information is dynamic. 



The figure below shows how the MCU_R£G may be used. 



LINE 


MASC1 MASC2 MASC3 AUDIO PRINTER 


MAY / MAY NOT 
INACTIVATE MOT 


MAY NOT NOT NOT NOT 


LINE U 
LINED 


P / 
OWN 


UP UP DOWN UP UP 


MSG 
TYPE 


TEXT ' 


XXX X 


STATUS 


X 


DATA 


X 


HP DATA 


X 


SPEECH 


X 


EMERGENCY 


X 


EXTPAK 


X 



In this case, only MASC1 is allowed to inactivate the MCU. 
All line handlers, except for MASC3 , are connected and 
intact. When APP_DIR receives an MPAK TEXT from MOBITEX 
network, it will be sent to MASC1, MASC2 and PRINTER. Since 
MASC3 does not have status line up, it does not receive any 
MPAKs. Received MPAK STATUS is to be sent to AUDIO. Other 
MPAKs are to be sent to MASC1. 

Observe that APP_DIR does not keep information of if MCU is 
active or inactive. Nor does APP_DIR know if radio NET has 
received an MPAK DIE from the MOBITEX network. It is che 
responsibility of RADIO_NET to keep information about this . 
If RADIO_NET notes which APP_DIR is not allowed to send to 
the MOBITEX necwork, the packets are returned to APP DIR 
with signal status set to signal_status_not_sent . 
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6.2 Register number two: FLEXLIST 

The FLEXLIST register has the structure shown in the figure 
below. 



• The HOB I TEX subscription number of the transferred 
subscriber. Up to seven M&N-numbers are allowed. 

■""The line handler to which the transferable has 
transferred. . 

• Tells login status. 

It can be: UNDER_LOGIN - the login sequence is not 
yet finished 
0K_L0GIN - the login sequence is 
finished and accepted 



6.3 Register number three: GROOFLIST 

The GROUPLIST contains a list of group MAN numbers. Op to 15 
MAN numbers is allowed. 



6.4 Register number four: CONNECTION_REG 

CONNECTION REG keeps information about the status of the 
speech line. It contains the following information: 

CONNECTION_STATUS 



CONNECTION PARTY HERE ■ 



• can be free, busy or 
waiting_for_hook_of f 

MAN number for connection part in 
the MCU 



CONNECTION_OTHER_PARTY - MAN number for the other connection 
~ part 



CONNECTION_CONN ID 



- connection identity for current 
speech line connection 
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7 REQUIREMENTS ON THE NETWORK LAYER IN- MCO 

Requirements on Che network layer in MCO (RADIO_NET) are 
listed below: 

1. Everything applicable to mobile terminal in document 
MOBITEX network layer for terminals, 5/1056 - A 296 
5171. 

2 All MPAKs that the application wants to send via radio 
and network layer to 

- be acknowledged to the application if the transmission 
was successful, 

- be returned to the application if the transmission 
failed. 

3 The signals hook_on and hook^off will be returned to the 
application if the transmission via radio 'fails. 

4 The following MPAKs, received by the MCD via radio, to 
be sent to the application: 

- all MPAKs of class PSOBCOM 

- all MPAKs of class PSOSCOM. 

Note that a transferred subscriber, connected to 
the MCO via an'MASC handler, can be. emergency 
receiver. 

- following MPAKs, belonging to the class CSDBSOM: 



+ ADDCONREQ 
+ SOSCONREQ 
+ EXTCONREQ 
+ CONORD 
+ DISCON 

- following MPAKs, belonging to the class DTESERV: 
+ LOGINREQ * ** 

+ LOGINREF ** 
+ LOGOOTORD ** 



+ FLEXLIST ** 

+ TIME 

+ GROOPLIST ** 

+ SOSRX * *** 

+ VICESOSRX * *** 

* These MPAKs can only have MPAK states that are not OK. 
** These MPAKs concern flexlist and grouplist. They are 

handled by the network layer and sent to the 

application. The reason for this is that the application 

has copies of flexlist and grouplist. 
*** Only if a terminal, connected to the MCD, has an 

emergency receiver transferred to it. 



A-J32 515M 
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8 REQUIREMENTS OH A PIXED TERMINAL 




The recruirements for a fixed terminal which is able to 
connect to the MOBITEX network as well as the MCU are as 
follows . 




Link layer 






Frames in the masc protocol for implemented: 




All control frames 


ACK, RACK, NACK, SENS, SACK 




Following information frames: 

B, M, E, R, F_P, F_Q, N 




Network layer- 






The MOBITEX network considers a fixed terminal, connected 
via an MCO, as a mobile terminal. This has the following 
consequencies as to which MPAKs may be sent and received by 
the terminal:. 




class PSOBCOMs 

The terminal is allowed to send and receive all MPAKs 
in this class. . 




class- PSOSCOM: 

An emergency sender can be a mobile subscriber or a 
transferable subscriber which is transferred to a 
mobile subscriber. A receiver can be a fixed terminal 
subscriber or a transferable subscriber. 
All emergency senders can send SOS and receive SOSACK. 
Furthermore, all mobile terminals are be able to 
receive SOS and SOSACK addressed to All terminals 
group MAN. 




class CSUBCOM: 

If the fixed terminal has one line for speech line 
connection, the following MPAKs can be received and 




CONREQ 






SOSCONREQ 
ADD CONREQ 






EXTCONREQ 

CONREA 

DISCON 






Connection to group will be made by the MCU by 
converting CONORD to CONREQ. 
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Class DTESERV: 

Following MPAKs may be sent: 
LOGINREQ . 
LOGOUT 
ACTIVE 
INACTIVE 
VICESOSRX 
SOSRX * 
FLEXLIST * 

* Only if the sender is a transferable subscriber. 



Following MPAKs shall be received: 
LOGINREQ 
LOGINGRA 
LOGI-NREF 
LOGODTORD 
VICESOSRX 
— SOSRX - — — 
GROCIPLIST 
. FLEXREQ 
TIME 



When the network layer receives masc frame N 'from the 
masc interface, it acts in the same manner as if the 
MPAK never leaved the fixed terminal. 
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9 PSEODO CODE FOR APPJDIR 


! 


In this pseudo code all procedures start with "P_", and all 
functions with "F_'' . 




REPEAT 

Wait for input . 
CASE input signal_type OF 
S MPAK sent on radio 
"IF from =~RADIO_NET THEN 

send this signal to origin 
ELSE 


i 


forget this signal 
END IF 
S_hook_on 

P hook on 
S hook off •• 
P_hook_off 
S line up 

~P_line_up 

S_line^down 
"~P line down 
S MPAK 

~P_MPAK 
conord timer 

CONNECTION_STATUS = free 
otherwise 

forget this signal 
END CASE input signal OF 
UNTIL forever 




P hook on 

IF ( from = AUDIO ) AND 


( CONNECTION_STATUS <> free ) 




send this signal to RADIO NET 

send signal S MPAK with MPAK = DISCON to 

CONNECTION LINE 

(MPAK. sender = CONNECTION OTHER PARTY 
MPAK. addressee = CONNECT ION_PARTY_HERE 
MPAK. type dependent. line number =~0 
MPAK . type - dependent . CONN ID=CONNECTION CONN ID) 

CONNECTION STATUS = free 




ELSE 

forget this signal 
END IF (from = ADDIO) AND ( CONNECT ION_STATUS ofree)... 
END P_hook_on 
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PJiook off 

IP from = AUDIO THEN 

IF CONNECTION_STATUS = waiting_f or_hook_of f THEN 
CONNECTION STATUS = busy 
send this signal to RADIO_NET 
reset conord_timer 
ELSE 

forget this signal 
END IF CONNECTION_STATUS = waiting for hook_off... 
ELSE 

IF (from=RADIO_NET) AND ( signal_status = 

signal_status_not_sent) THEN 

forget this signal 

send signal S_MPAK with MPAK = DISCON to 
CONNECTION LINE 

( MP AK. sencTer = CONNECTION_OTHER_PARTY 
MPAK. addressee = CONNECT I ON_P ART Y_HERE 
MPAK.type dependent. line number = 0 
MPAK.type2deoendent.CONN_ID = CONNECT I ON_CONN_ID ) 
CONNECT ION_STATUS = free 

- ELSE 

forget this signal 
END IF (from = HADIO_NET) AND (signal_status = . . . ) 
END IF from - AUDIO..." 
END P_hook_off 



P_line_down 

mark origin in MCU_REG as line_down 

FOR all MAN in our flexlist pointing at origin DO 

send signal S_MPAK with MPAK = logout to RADIO_NET 
( MPAK. sender = MAN in question from flexlist 
MPAK. addressee = the MOB I TEX network 
MPAK.type_dependent part = MCU_MAN ) 
remove MAN in question from our flexlist 
END FOR all MAN in our flexlist pointing... 
END P_line_down 



P line up 

send signal S MPAK with MPAK = grouplist to origin 
( MPAK. sender = the MOBITEX network 
MPAK. addressee = MCU_MAN 
MPAK.type_dependent_part - our grouplist ) 
send signal S_MPAK with MPAK « flexreq to origin 
( MPAK. sender = the MOBITEX network 
MPAK. addressee = MCU MAN ) 
mark origin in MCU_REG as line_up 
END P_line_up 
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P_HPAK 

IF signal status = signal_status ok THEN 
IF frora~= RADIO_NET THEN 
P_MPAK_f rom_radio 

P_MPAK_from_other 
END IF from = HADIO_NET ... 
ELSE 

IF origin = from THEN 

forget this signal (can't send this signal in any 
direction } 

ELSE 

IF origin = RADIO_NET THEN 

forget this signal (Never send back MPAK to 
network) 

ELSE 

IF MPAK.unknown_f = 0 THEN 
CASE MPAK.packet_ciass OF 
PSUBCOM,PSOSCOM 

signal status = signal_status_ok 
signal~type = S_not_sent_MPAK 
send this signal to origin 
CSDBCOH 

CASE MPAK. pack et_type OF 
CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ 
signal_status = signal_status_ok 
signal_type = S_not_sent MPAK - 
send this signal to origin 
CONNECTION_STATOS = free 
otherwise ~ 

forget this signal 
END CASE MPAK. packet type... 
DTESERV 

CASE MPAK. packet type OF 
VICESOSRX,SOSRX 

signal_status = signal_status_ok 
signal_type = S_not_sent_MPAK~ 
send this signal to origin 
LOGINREQ 

remove MPAK.type_dependent_part from our 
flexlist 

signal_status = signal status_ok 
signal~type = S_not_sent MPAK 
send this signal to origin 
otherwise 

forget this signal 
END- CASE MPAK.packet_type. . . 
END CASE MPAK. class. . . 
ELSE 

forget this signal 
END IF MPAK.unknown_f . 
END IF origin. . . 
END IF origin... 
END IF signal_status. . . 
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P_MPAK_from_otner 

mark origin in MCU REG as line up 
CASE MPAK. packet class OP 
PSUBCOM.PSOSCOM ~ 

IP MPAK . unknown_f = 1 THEN 

IF (F_get_receiver_MAN in our grouplist ) OR- 
[F_get_receiver_MAN = MCU_MAN ) THEN 

forget this signal 
ELSE 

IP F_get_receiver_MAN in our flexlist THEN 
remove F_get receiver_MAN from our flexlist 
send signal S_MPAK with MPAK = LOGOUT to RADIO NET 
( MPAK. sender = F_get receiver_MAN "" 
MPAK. addressee = the MOB I TEX network 
MPAK.type_dependent_oarf = MCU MAN ) . 
END IF F_get_receiver_MAN in our" flexlist ~ 
send this signal to RADIO NET 
END IF tF_get_receiver_MAN In our grouplist... 
ELSE ( IF MPAK. unknown f = 1 ...) 

IF (MPAK. state <> OK~) OR { MPAK.digital_f =1 ) THEN 

signal_type = S_returned_incorrect_MPAK 

send this signal to origin 
ELSE 

IF (F_get_transmitting_MAN = MCD_MAN ) or 
(P_get_transmitting_man in our flexlist with status 
ok login ) THEN 

send this signal to RADIO NET 
ELSE 

send signal S_MPAK with MPAK = LOGOOTORD to origin 
(MPAK. sender = the MOBITEX network 
MPAK . addressee = MCU_MAN 

MPAK.type_dependentjpart= F get transmittina MAN) 
signal_type = S not_sent_MPAK ~ 
signal~status =~signal_status_ok 
send this signal to origin 
END IP (F get transmitting MAN = MCU MAN... 
END IF MPAK. state... 
END IF MPAK. unknown f... 
CSDBCOM 

CASE MPAK. packet type OF 
CONREQ , ADDCONREQTSOSCONREQ , EXTCONREQ 
IF ( MPAK . unknown_f - 0 ) and 
( MPAK.mailbox_f = 0 ) and 
( MPAK.sendlist_f = 0 ) and 
( mpak. state = OK ) THEN 
IF (F_get transmitting MAN = MCU_MAN ) or 
(P_get_transmitting_MAN is in our flexlist with 
status ok_login ) 
THEN 

IF CONNECTION STATUS = free THEN 
CONNECT ION_3Ti ne = origin 
CONNECTION_status = busy 
send this signal to RADIO_NET 



Exhibit 2, p. 827 



j'l/1056 - A 296 5175 Ue 

CantelMobitex- vu^^^ fESi 



ELSE 

signal_type = S_not_sent_MPAK 
signal_status = signal scatus_ok 
send this signal to origin 
END IF CONNECTION STATUS = free... 
ELSE 

send signal S_MPAK with MPAK = LOGOUTORD 
origin 

( MPAK. sender = the MOB I TEX network 
MPAK. addressee = MCU_MAN 
MPAK.type_deDendent_part = 
F_get transmitting_MAN ) 
signal_type * S_not_sent'_MPAK 
signal_status = signal status_ok 
send this sianal to origin 
END IF (F_get_transmitting MAN = MCU MAN... 
ELSE 

signal_type = S_returned_incorrect_MPAK 
send this signal to origin 
END IF ( MPAK.unknown_f =0... 



IF ( CONNECTION STATUS '= waiting for hook_off) and 
( origin = CONNECTION_line ) THEN 

forget this signal ~ 
. send signal S_hook_off to RADIO_NET 

CONNECT ION_STATUS = busy 

reset conord_timer 
ELSE 

forget this signal 
DISCON 

IF ( CONNECTION_STATUS <> free) and 
( origin = CONNECTION. line ) THEN 

forget this signal 

send signal hook on to RADIO NET 

CONNECTION_STATUS = free 
ELSE 

forget this signal 
otherwise 

forget this signal 
END CASE MPAK. packet type... 
DTESERV 

CASE MPAK.oacket type OF 

LOGINREQ , LOGOUT , ACTIVE , INACTIVE , VICESOSRX , SOSRX , FLEXLIST 
IF (MPAK. state = ok ) AND 
( MPAK.digital_f = 0 ) AND 
( MPAK,raailfaox_f = 0 ) AND 
( MPAK.sendlist_f = 0 ) AND 
( MPAK.unknown_f = 0 } AND 
( MPAK.extern_f - 0 ) AND 
• ( MPAK. addressee = HOB I TEX network ) THEN 
CASE MPAK.oacket_type OF 
LOGINREQ , ACTIVE , INACTIVE , FLEXLIST 
IF MPAK. sender = MCU MAN THEN 
CASE MPAK.packet_type OF 
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LOGINREQ 

IF MPAK.typejdependentjpart in our flexlist 
with status = ok_login THEN 

send signal S_MPAK with MPAK LOGINGRA to 

origin 

( MP AK. sender = the MOBITEX network 
mpak. addressee = mcu_man 
MPAK.type_dependent_part = 
=<old>MPAK.type_dependent_part ) 
forget this signal 
ELSE 

IP more space exists in our flexlist THEN 
mark MPAK. type dependent_oart in our 
flexlist 

with scatus=under_login and line = 
origin 

send this signal to RADIO_NET 
• ELSE 

signal_type = S_not_sent_MPAK 
signal~status =~signal_status_ok 
— -.send this signal to origin ~ 
END IF more space in our flexlist... 
END IF MPAK.type_dependent_part in our... 
ACTIVE , INACTIVE 

IF origin may inactivate THEN 
P_line_down 

send this signal to HADIO_NET 
ELSE 

P_line_down 

forget~this signal 
END IF origin may activate/inactivate... 
FLEXLIST 

FOR all MAN in MPAK . FLEXLIST not in our 
flexlist 

with status ok_login DO 

send signal S_MPAK with MPAK = logoutord 
to origin 

( MPAK. sender - the MOBITEX network 
MPAK.addressee = MCU_MAN 
MPAK.type_dependent_part = MAN in 

question ) 

END FOR all MAN in MPAK. FLEXLIST not in our... 
forget this signal 
END CASE MPAK.packet_type 
ELSE ( IF MPAK. sender = MCU MAN) 

signal_type = S_returned^_incorrect_MPAK 
send this signal to origin 
END IF MPAK. sender = MCU_MAN. . . 
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VICESOSRX,SOSRX 

IF MPAK. sender in our fiexlist. with status 
ok_login THEN 

send this signal to RADIO_NET 
ELSE 

signal_type = S_not_sent_MPAK 
signal_status = signal_status_ok 
send this signal to origin from 
END IF MPAK. sender in our fiexlist with status. 
LOGOUT 

IF MPAK. sender in our fiexlist with any status 
THEN 

delete MPAK. sender from our fiexlist 
MPAK.type_dependent_part = MCU_MAN 
send this signal to~RADIO NET " 
ELSE 

forget this signal 
END IF MPAK. sender in our fiexlist ... 
END CASE MPAK. packet type... 
ELSE 

signal.- type .j? S_returned_incorrect_MPAK 
send this signal to origin 
END IF (MPAK. state = ok... 
otherwise 

signal_type = S_returned_ i _incorrect_MPAK 
send this signal to origin 
END CASE MPAK.packet_type. . . 
END CASE MPAK. Class. . . 

2ND P MPAK from other 



P MPAK from radio 
CASE MPAK. class OF 
PSDBCOM,PSOSCOM 

IF F get_receiver MAN in our fiexlist THEN 

send this signal to line in question 
ELSE 

IF ( F get_receiver_MAN = MCU_MAN ) OR 
( F_get_receiver_MAN in our grouplist ) THEN 
CASE MPAK. class OF 
PSOBCOM 

CASE MPAK.packet_type OF 
TEXT 

P_copy_and_send_signal{ text ) 
STATUS 

P_copy_and_send_signal( status ) 
HPDATA 

P_copy_and_send signal ( hpdata ) 
DATA 

P_copy_and_send_signal( data ) . 
EXTPAK 

P_copy_and_send_signal (EXTPAK) 
otherwise ~" 

forget this signal 
END CASE MPAK. packet type... 
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IF ( MPAK.packet_type = SOS or SOS INFO ) 

AND ( MPAk. addressee = all terminal group MAN ) 

THEN 

IF MPAK. sender in out flexlist THEN 

send this signal to line in question 
ELSE 

P_copy_and_send_signal( emergency ) 
END IF MPAK. sender in our flexlist... 
ELSE 

P_copy and_jsend_signal{ emergency ) 
END IF (~MPAK.packet_type .=. SOS or SOSINFO.. 
END CASE MPAK. class... 
ELSE 

( This case can not appear; the network layer shall 

take care of unknown MPAKs from the network) 
MPAK. unknown f = 1 
send t-his signal to RADIO NET 
END IF ( F_get_receiver_MAN~= MCD_MAN... 
END IF F_get_receiver MAN in our flexlist... 
CSOBCOM ....... _. 

CASE MPAK.packet_type OF 

CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ 
IF MPAK. State <> ok THEN 

P_discon 
ELSE 

IF F_get_receiver_MAN in our flexlist THEN 
CONNECT I ON_S T ATOS = waiting_f Dr_hook_of f 
CONNECTION^ INE = line in question from flexlist 
CONNECTION_PARTY_HERE = MPAK. addressee 
CONNECTION_OTHER_PARTY = MPAK. sender 
CONNECTION_CONN_ID =MPAK. type_dependent . conn_id 
send this signal to line in question 

IF F_get_receiver_MAN = MCO_MAN THEN 

CONNECTION_STATUS = waiting_for_hook_of f • 
CONNECTION_PARTY_HERE = MPAK. addressee 
CONNECTION OTHERJPARTY = MPAK. sender 
CONNECTIONj:QNN_ID =MPAK. type_dependent . conn_id 
send this signal to first line in MCD_REG with 
(line_status = up) AND (msg_type = speech) 
IF no such line THEN 
forget this signal 

CONNECT ION_STATDS = waiting_for_hook_of f 
send signal S_hook on to HADIO_NET ~ 
ELSE 

CONNECT I 0N_L INE = line in question from 
MCU_REG 
END 
ELSE 

forget this signal 
send signal S_hook_on to RADIO_NET 
END IF ( F get receiver_MAN = MCU_MAN... 
END IF F GET"receiver MAN in our flexlist... 
END IF MPAK. state <> ok 
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IP CONNECTION STATUS = free THEN . 

IF F get receiver MAN in our grouplist THEN 
MPAK . packet_type = CONREQ 
CONNECT ION_STATUS = waiting_£or_hoak_o££ 
CONNECT ION_PARTy_HERE = HPAK. addressee 
CONNECTION_OTHER_PAR.TY = MPAK. sender 
CONNECTION CONN_ID= MPAK.type_dependent.conn_id 
send this signal to first line in MCU_REG with 
( line_status = up ) AND ( msg_type = speech ) 
IF no such line THEN 
forget this signal 
CONNECTION STATUS = free ' 
send signal S hook on to RADIO_NET 
ELSE 

CONNECTION^ INE = line in question from HCO_REG 

set timer: conord_timer 
END 
ELSE 

forget this signal 
send signaT S_hook_6h to HADTOJNET 
END IF F_get_receiver HAN in our grouplist... 
ELSE 

forget this signal 
END IF CONNECTION_STATDS = free... 
DISCON 

P_discon 
otherwise 

forget this signal 
END CASE MPAK. packet type... 
DTESERV 

CASE MPAK. pack et_type OF 
LOGINREQ , LOGINHEF , LOGOUTOHD 

IF MPAK.type_dependent in our flexlist THEN 
send this signal to line IN QUESTION 
remove MAN in question from our flexlist 
ELSE 

forget this signal 
END IF MPAK.type_dependent in our flexlist THEN 
LOGINGRA 

IF MPAK. type dependent in our flexlist THEN 
mark in our flexlist status = ok_login 
send this signal to line in question 

send signal S_MPAK with MPAK = logout to RADIO_NET 
( MPAK, sender = MCU_MAN 
MPAK. addressee = MOB I TEX network 
MPAK. type dependent_part = MAN in question 
■END IF MPAK.type_dependent in our flexlist 
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FOR all MAN in this signal who are not in our fiexlist 
send signal S_MPAK with MPAK = logout to RADIO_NET 
( MPAK . sender = MCU MAN 
MPAK. addressee ■ ""MOBITEX network 
MPAK. type dependent_part = MAN in question) 

END 

FOR all MAN in our fiexlist who are not in this signal 
send signal S_MPAK with MPAK = logoutord to line in 
question 

( MPAK. sender = MOBITEX network 
MPAK. addressee = MCO_MAN 

MPAK.type_dependent_part = MAN in question ) 
remove MAN in question from our fiexlist 
END 
TIME 

send a copy of this signal to all lines 
GROOPLIST . 

store grouplist from this signal in our register 
send a copy of this signal to all lines 

SOSRX,-VICESOSRX ■•- 

IF F_get_receiver_MAN in our fiexlist THEN 

send this signal to line in question 
ELSE forget this signal 
END CASE MPAK. packet type OF... 
END CASE MPAK. class. . 
MD P MPAK from radio 



P_copy_and_send signal ( type } 

send a copy to all lines in MCD_REG with 

( line_status = up ) and [ msg_type = type ) 

END P_copy_and_send_signal 



P_discan 

IF CONNECTION STATUS <> free 

send this sTgnal to CONNECTION^ INE 
. CONNECTION_STATUS = free 
ELSE 

forget this signal 
END 

END P_discon 
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F_get receiver_MAN 
CASE MPAK. state OF 
ok,£rora_mail 

F _9 et _ receiv er_MAN = MPAK. sender 
otherwise 

F_get receiver MAN = MPAK. addressee 
END CASE 
END F_get_receiver_MAN 



F_get_transmitting_MAN 

IF MPAK.unknown_f = 0 THEN 



= F_get_receiver_MAN 
END F_get_transoitting_MAN 
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10 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

. Rl-09, 3 
Rl-16, 3 



Below are the reference designations listed. 

Reference Section 

Rl-01 .- Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

111-11 Interface requirements-, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

&L-n Physical layer, mobile terminals 

Rl-18 Radio, equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

R!-20 Other requirements, mobile terminals 
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HOBITEX 

General requirements, mobile term. • 



The general requirements for MOBITEX mobile terminals are 
described in this document. These include environmental 
requirements, power supply requirements, the minimum 
requirements for controls and indicators and special 
requirements in connection with the type approval testing. 
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1 ENVIRONMENTAL REQUIREMENTS 

The equipment must be operational also under the extreme 
temperature' conditions. No error functions which can 
interfere with the operation of the MOBITEX network must 
occur under any environmental condition. 



1 . 1 Temperature 

The normal operational temperature" range: 

+15 to +35 degrees C. 
The extreme operational temperature range: 

-25 to +55 degrees C. 

The equipment should be such that it is not damaged by 
storage in the temperature range of: 

-40 to +70 degrees C. 

1.2 Relative humidity 

Mobil terminal should be able to withstand 20-75% RE. 

1.3 Vibrations 

The equipment should be able to withstand a vibration test 
in accordance with IEC publication 68-2-6: 

10 - 55 Hz +/- 0,15 mm movement. 

55 - 150 Hz 20 m/s square acceleration. 

Sweep rate: 1 octave per. minute 

Duration: 2 hours in each of the three directions. 

The equipment should not be in operation during the test 
but should comply with the requirements in the MOBITEX 
terminal specification after the test. 
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2 POWER SUPPLY 

2.1 nominal voltage 

The nominal voltage is optional and should be stated by 
the manufacturer. 



2.2 Voltage limits 

Equipment designed for working from lead acid accumulators 
in a vehicle should comply with the specifications when 
the voltage varies from 0.9 to 1.3 times the nominal 
voltage. 

Equipment designed for operating on an alternating voltage 
should comply with the specifications when the voltage 
varies by +10%. 

If these limiting values are exceeded, error functions 
which can interfere with the operation -of the network 
should not occur. 



3 HARKING 

The equipment should be clearly marked with the 
manufacturer, type designation, serial number, approving 
text {"Approved by ... ") and registration number of the 
type approval. The marking should be engraved on metal and 
permanently fixed to the equipment. 

The mobile terminal's subscription number should be 
clearly visible or accessible. 



3.1 Electronic serial number check 

The serial number should.be stored together with the 
terminal subscription HAN and permanently in such a way 
that they are impossible to change by software or by 
unauthorised persons, preferably in enchrypted form. 

The serial number of the equipment should be checked in 
the terminal against the serial number stored together 
with the MAN at power on. If the numbers are not equal, it 
should be impossible to use the equipment. 

In addition, the serial number (ESN) is sent to the 
network at "activation", to be checked with the serial 
number stored in the network (see reference Rl-09). 



■353 
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There are no requirements for type approval of controls. 
There are certain recommendations however. 

If number keys for number keying are used, they should 
comply with one of the following minimum configurations. 

12345*AB 
67890#CD 

12 1 2 3 A 

3 4 4 5 6 B 

5 6 7 8 9 C 

7 8- * 0 # D 

9 0 
* # 

- A B. 

C D 

The following recommendations apply for the A, B, C and D 
keys. The D key should have the data send function. If 
there is a speech facility, key C is used for "speech 
request". The key should be marked with T. Keys A-and B 
can be used for status or another function and marked 
according to use. 

International standards should be followed if a completely 
alphanumeric keyboard is used. The number keys on the 
keyboard can then be used for number keying as well. 



5 INDICATORS 

An indicator with yellow or amber colour should indicate 
when the power is switched on. 

An indicator with green colour should indicate with a 
steady light when the mobile terminal is in contact with 
the HOBITEX network and with a twinkling light when it is 
not (base search mode). 
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6 TYPE APPROVAL TESTING 

Except the equipment described in the chapters below, 
requirements may be specified by the network operator 
(please refer to reference Hl-06) for equipment such a: 

- Portable antennas 

- Cabling and terminations 

- Terminal display 



6.1 Equipment to be type approved 

The type approval test applies to the radio equipment and 
to the physical, link and network layers of the mobile 
equipment-according to these specifications. Application 
layer functions are only tested if under special 
requirements when installed. 

The type approval only applies to the software tested. If 
a change is made in any software scored in the same 
storage unit as the software handling the tested 
functions, a new type test must be made. The testing 
authority should determine at its discretion and based on 
documentation of the modifications, wether new 
measurements are necessary for a new approval. 

Optional terminal equipment to be connected to the radio 
control unit is not type tested. 



6.2 Normal test conditions 

The mobile terminal should be tested in the normal 
environment stated above. The specified data should be 
complied with for all combinations. 

Terminals designed for operating on lead acid accumlators 
in vehicles should be tested at 1.0 times the nominal 
voltage. 

The terminal should be ready for operation within 1 minute 
of switching on the power. 



6.3 Extreme test conditions 

Additional environmental requirements can be made' in 
reference Rl-06 (Network operator information). 
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The mobile unit should be tested at the lower and upper 
limits in the temperature and voltage ranges stated above. 

Before testing is carried out, the equipment should have 
achieved thermal equilibrium in the test chamber. The 
power supply should be switched off during this period. 
Measurements should be carried out in such a sequence and 
with relative humidity controlled so that excessive 
condensation does not occur. 

Testing at the upper temperature limit should begin with 
the sender in the send position for 1 minute and receiving 
for 4 minutes after which measurement's are carried out. 

Testing at the lower temperature limit should 
1 minute after switching" on the power supply. 
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6.4 Teat connections, interfaces and controls 

For the type approval test, the mobile terminal should be 
equipped with test ' connections and manual controls to 
permit the measurements that are necessary to verify that 
the specification requirements are complied with. This 
applies particularly to the requirements stated in 
'reference Rl-18 {"Radio equipment, mobile terminals" and 
"Measurement methods"). These connections and controls can 
be implemented by external test adaptors during the test. 

For the type approval test, the equipment should also be 
equipped with the "Machine interface (MASC)" as described 
in reference Rl-19 ("Other interfaces, mobile terminal", 
minimum basic and type test functions). This interface can 
be implemented by an external test adaptor during the 
test. 

Equipment intended to be used as partially active in 
"MOBXTEX should be possible to operate as a normal mobile 
terminal during the tests, i.e. continuously listening to 
MOBITEX. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on- Please note that a section could be 
referred to several times on the same page. 

Rl-06, 6 
Rl-09, 4 

ri-18, a 

Rl-19, 8 



Below are the reference designations listed. 
Reference . Section 

Rl-01 Arrangement of the documents 

;; ,Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

R1-0S Application layer 

Rl-09 Network layer 

Rl-ll Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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